From: Christian Deacon <gamemann@gflclan.com>
To: David Ahern <dsahern@gmail.com>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>, xdp-newbies@vger.kernel.org
Subject: Re: AF_XDP Side Of Project Breaking With XDP-Native
Date: Sun, 24 May 2020 16:25:27 -0500 [thread overview]
Message-ID: <edfe88b4-7006-f571-17c3-087c88bbaa2f@gflclan.com> (raw)
In-Reply-To: <791e4566-0944-399f-fade-550c60ea8643@gmail.com>
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 parent reply other threads:[~2020-05-24 21:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-22 15:22 AF_XDP Side Of Project Breaking With XDP-Native Christian Deacon
2020-05-22 15:51 ` Jesper Dangaard Brouer
2020-05-22 16:12 ` Christian Deacon
2020-05-24 17:35 ` David Ahern
2020-05-24 18:13 ` Christian Deacon
2020-05-24 18:58 ` David Ahern
2020-05-24 19:27 ` Christian Deacon
2020-05-24 20:23 ` David Ahern
2020-05-24 21:25 ` Christian Deacon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=edfe88b4-7006-f571-17c3-087c88bbaa2f@gflclan.com \
--to=gamemann@gflclan.com \
--cc=brouer@redhat.com \
--cc=dsahern@gmail.com \
--cc=xdp-newbies@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).