Hey David, Thank you for this!I will be looking into implementing the packet parsers into my current projects with XDP to simplify code :)
In regards to the AF_XDP issue, now that I know it should be working with the `virtio_net` driver under XDP-native, I'm not sure why I keep receiving a device is busy error after the first XDP attach. I also have a second issue with Compressor, AF_XDP, and XDP-native which is the AF_XDP program isn't sending packets back to the client via TX. It works fine with XDP-generic, though.
https://github.com/Dreae/compressor/blob/master/src/compressor_cache_user.c#L283I discovered that `rcvd` is returning 0 when XDP-native is enabled, but returns a number higher than 0 when using XDP-generic. I'd imagine this is due to outdated AF_XDP code, though. I'll continue digging deeper into that issue after the first issue is resolved (the device is too busy error).
Thank you again for all the help! On 5/24/2020 3:23 PM, David Ahern wrote:
On 5/24/20 1:27 PM, Christian Deacon wrote:As of right now, the packet processing software I'm using forwards traffic to another server via XDP_TX. It also drops any traffic via XDP_DROP that doesn't match our filters (these filters aren't included in the open-source project linked below). Do you know if there would be any real performance advantage using XDP-native over XDP-generic in our case with the `virtio_net` driver for XDP_TX and XDP_DROP actions? We're currently battling (D)DoS attacks. Therefore, I'm trying to do everything I can to drop these packets as fast as possible.native will be much faster than generic.If you would like to inspect the source code for this project, here's a link to the GitHub repository: https://github.com/Dreae/compressor I'm also working on a bigger open-source project with a friend that'll drop traffic based off of filtering rules with XDP (it'll be version two of the project I linked above) and we plan to use it on VMs with the `virtio_net` driver. Therefore, it'll be useful to know if XDP-native will provide a performance advantage over XDP-generic when dropping packets.Looking at: https://github.com/Dreae/compressor/blob/master/src/compressor_filter_kern.c A packet parser would simplify that code a lot - and make it more readable. For example: https://github.com/dsahern/bpf-progs/blob/master/ksrc/flow.c https://github.com/dsahern/bpf-progs/blob/master/ksrc/flow.h It is modeled to a huge degree after the kernel's flow dissector. It needs to be extended to handle IPIP, but that is straightforward. The flow struct can also expanded to save the various header locations. You don't care about IPv6 so you could make the v6 code based on #ifdef CONFIG options to compile it out. I have an acl program that uses it, but I make too many changes to it right now to make it public. Example use of the flow parser: void *data_end = (void *)(long)ctx->data_end; void *data = (void *)(long)ctx->data; struct ethhdr *eth = data; struct flow fl = {}; void *nh = eth + 1; u16 h_proto; int rc; if (nh > data_end) return true; h_proto = eth->h_proto; /* vlan handling here if relevant */ rc = parse_pkt(&fl, h_proto, nh, data_end, 0); if (rc) // you might just want DROP here return rc > 0 ? XDP_PASS : XDP_DROP; ... make decisions based on L3 address family (AF_INET), L4 protocol , etc
|