[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xdp-newbies
Subject:    Re: AF_XDP Side Of Project Breaking With XDP-Native
From:       Christian Deacon <gamemann () gflclan ! com>
Date:       2020-05-24 21:25:27
Message-ID: edfe88b4-7006-f571-17c3-087c88bbaa2f () gflclan ! com
[Download RAW message or body]

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#L283


I 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
[prev in list] [next in list] [prev in thread] [next in thread]