Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specialise BPF code for IPv4 & IPv6 to optimise performance #2

Closed
sauercrowd opened this issue Sep 16, 2020 · 1 comment
Closed

Specialise BPF code for IPv4 & IPv6 to optimise performance #2

sauercrowd opened this issue Sep 16, 2020 · 1 comment

Comments

@sauercrowd
Copy link
Contributor

sauercrowd commented Sep 16, 2020

We currently map IPv4 addresses to IPv6 ones, and then work on IPv6 addresses exclusively. This is a significant performance hit, since we need to hash 4x more bytes (roughly).

If we split the code into IPv4 and IPv6 specific, we can determine the protocol in New and then attach the correct BPF filter. This should give us a nice boost for IPv4.

@lmb
Copy link
Contributor

lmb commented Sep 18, 2020

Thoughts on what has to happen:

  • Split packet_element into two structs
  • Modify add_to_node to take a pointer + length instead of pointer to packet_element

Making process_packet generic is going to be tricky. Maybe we can describe each level as a table?

static const struct level_desc level1[] = {
	{ADDRESS_NET, PORT_SPECIFIED, ADDRESS_IP, PORT_SPECIFIED}
	{ADDRESS_IP, PORT_WILDCARD, ADDRESS_IP, PORT_SPECIFIED}
	{ADDRESS_IP, PORT_SPECIFIED, ADDRESS_IP, PORT_WILDCARD}
};

Then we could use a for loop + #pragma unroll to generate one version for ipv4 and ipv6 each. That would still involve a lot of copypasta, so maybe there is a better solution.

lmb added a commit that referenced this issue Jan 19, 2021
There is an important optimization to be had: since we know the IP
version of a socket we can attach a socket filter that is specialised
to IPv4 or IPv6. This is a big win for IPv4, since we end up hashing
a lot less data.

We also generate less code, so we are closer to not needing a higher
optmem limit for IPv4.

Fixes #2
Updates #13
@lmb lmb closed this as completed in d586360 Feb 3, 2021
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

No branches or pull requests

2 participants