Skip to content

Limit filter hwports mask to only interfaces with the filtered IP - #336

Open
zhuyifei1999 wants to merge 1 commit into
Xilinx-CNS:masterfrom
zhuyifei1999:filter-hwport-restrict
Open

Limit filter hwports mask to only interfaces with the filtered IP#336
zhuyifei1999 wants to merge 1 commit into
Xilinx-CNS:masterfrom
zhuyifei1999:filter-hwport-restrict

Conversation

@zhuyifei1999

Copy link
Copy Markdown
Contributor

Ths change adds a module option to, when a filter is installed, the filter is only installed to interfaces with the IP of that filter. For wild sockets, Onload duplicates the filter for each local address. The original behavior would be that each such filter would be installed to every active interface. Assuming N interfaces and each interface has a different IP, this would result in N filters being installed to each interface, and N^2 filters installed in total. With this option on, however, each interface would get only one filter and N filters being installed in total.

When new local addresses are being added, the code will retroactively add apply it existing filters, just like original behavior. However, if an existing local address of one interface is added to a new interface, the original code ignores it, since it assumes that the filter for that existing local address has already been added to all active interfaces. This assumption no longer holds with this patch, so the filters will be re-applied.

For local address removal, original code postpones filter removal until the local address is unused on all active interfaces. This behavior is preserved because local address removal is a rare operation not worth optimizing for, in my opinion.

The module option is defaulted off for backwards compatibility, in case a user depends on the original behavior, such as relying on a connection being accelerated even when it is received on an interface when the destination address corresponds to a different interface.

Multicast logic is untouched. DNAT logic I was unable to test.

Ths change adds a module option to, when a filter is installed, the
filter is only installed to interfaces with the IP of that filter.
For wild sockets, Onload duplicates the filter for each local
address. The original behavior would be that each such filter would
be installed to every active interface. Assuming N interfaces and
each interface has a different IP, this would result in N filters
being installed to each interface, and N^2 filters installed in
total. With this option on, however, each interface would get only
one filter and N filters being installed in total.

When new local addresses are being added, the code will
retroactively add apply it existing filters, just like original
behavior. However, if an existing local address of one interface
is added to a new interface, the original code ignores it, since it
assumes that the filter for that existing local address has already
been added to all active interfaces. This assumption no longer holds
with this patch, so the filters will be re-applied.

For local address removal, original code postpones filter removal
until the local address is unused on all active interfaces. This
behavior is preserved because local address removal is a rare
operation not worth optimizing for, in my opinion.

The module option is defaulted off for backwards compatibility,
in case a user depends on the original behavior, such as relying on
a connection being accelerated even when it is received on an
interface when the destination address corresponds to a different
interface.

Multicast logic is untouched. DNAT logic I was unable to test.

Signed-off-by: YiFei Zhu <zhuyifei@google.com>
@zhuyifei1999
zhuyifei1999 requested a review from a team as a code owner July 20, 2026 19:28
@zhuyifei1999

Copy link
Copy Markdown
Contributor Author

This patch complements PR #335 so fewer filters are created in multi-NIC machines where those NICs have different IPs

@mina

mina commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Hi folks!

This is a somewhat critical issue & fix for users. If you could take a look that would be much appreciated! Thanks! We're available to address any issues you may find.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants