From: "Nguyen, Anthony L" <anthony.l.nguyen@intel.com> To: "sven.auhagen@voleatech.de" <sven.auhagen@voleatech.de>, "brouer@redhat.com" <brouer@redhat.com> Cc: "toke@redhat.com" <toke@redhat.com>, "dsahern@gmail.com" <dsahern@gmail.com>, "xdp-newbies@vger.kernel.org" <xdp-newbies@vger.kernel.org>, "intel-wired-lan@lists.osuosl.org" <intel-wired-lan@lists.osuosl.org>, "ThomasPtacek@gmail.com" <ThomasPtacek@gmail.com> Subject: Re: [Intel-wired-lan] bpf_redirect and xdpgeneric Date: Mon, 28 Sep 2020 18:04:14 +0000 [thread overview] Message-ID: <f1a1a7c89fce4ba5c78da65700e02d353bb9e5d4.camel@intel.com> (raw) In-Reply-To: <20200928162010.wpv6ukqscuxaxtnj@svensmacbookair.sven.lan> On Mon, 2020-09-28 at 18:20 +0200, Sven Auhagen wrote: > On Mon, Sep 28, 2020 at 05:24:49PM +0200, Jesper Dangaard Brouer > wrote: > > On Fri, 18 Sep 2020 14:27:45 -0600 > > David Ahern <dsahern@gmail.com> wrote: > > > > > On 9/18/20 12:42 PM, Thomas Ptacek wrote: > > > > The setup is pretty simple. There's an eno1 (igb driver), to > > > > which our > > > > default route points. On the same box are several VMs. There's > > > > a tap > > > > interface (for each VM, call it tapX). Traffic for a VM flows > > > > in from > > > > the Internet on eno1 and is directed to tapX; the response > > > > traffic > > > > flows in the other direction. > > > > > > > > I'm deliberately simplifying here: > > > > > > > > eno1 runs an XDP program that does some lightweight IP > > > > rewriting from > > > > anycast addresses to internal VM addresses on ingress. eno1's > > > > XDP > > > > program currently XDP_PASS's rewritten packets to the IP stack, > > > > where > > > > they're routed to the VM's tap. This works fine. > > > > > > > > tapX runs an XDP program that does the same rewriting in > > > > reverse. > > > > Right now, it also XDP_PASS's packets to the stack, which also > > > > works > > > > --- the stack routes response traffic out eno1. > > > > > > > > I'm playing with XDP_REDIRECT'ing instead of XDP_PASS'ing. > > > > > > > > I have the ifindexes and MAC addresses (and those of IP > > > > neighbors) in > > > > a map --- a normal HASH map, not a DEVMAP. Using that map, I > > > > can > > > > successfully redirect traffic from tapX to arbitrary other tap > > > > interfaces. What I can't do is redirect packets from tapX to > > > > eno1, > > > > which is what the system actually needs to do. > > > > > > > > > > XDP_REDIRECT sends the packet to a devices ndo_xdp_xmit function. > > > tap > > > implements it hence eno1 -> tap works; igb does not meaning tap > > > -> eno1 > > > fails. > > > > There is clearly a real-life use-case for adding native-XDP support > > for > > igb driver. Sven (cc) have implemented this (v6[1]), but something > > is > > causing this patch to not move forward, what is stalling Intel > > maintainers? > > The holdup is from the Intel guys. > There is a v7 with the changes for Kernel 5.9 but it was only posted > on > the Intel list: > > https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20200902203222.185141-1-anthony.l.nguyen@intel.com/ > > They tested it last week so it should hopefully be merged in the next > window. There were some email issues which prevented us from sending it out sooner (after it was tested). The issue was resolved Friday, I just sent the patch to netdev: https://patchwork.ozlabs.org/project/netdev/patch/20200928175908.318502-2-anthony.l.nguyen@intel.com/ Thanks, Tony > > > > To Thomas, you could try out the patch[2] and report back if it > > works > > for you? (I think it will help moving patch forward...) > > > > I would be interested if it works for you as well. > > Best > Sven > > > [1] > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fnetdev%2F20200902054509.23jbv5fyj3otziq2%40svensmacbookair.sven.lan%2F&data=02%7C01%7Csven.auhagen%40voleatech.de%7Ccbd762e5a024488f491b08d863c2b6cb%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637369035229290801&sdata=Pv%2BTEQeY4lcPnIprg0n6K0nHOMMlMo2qlrcmxqWNuLY%3D&reserved=0 > > [2] > > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fnetdev%2Fpatch%2F20200902054509.23jbv5fyj3otziq2%40svensmacbookair.sven.lan%2F&data=02%7C01%7Csven.auhagen%40voleatech.de%7Ccbd762e5a024488f491b08d863c2b6cb%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637369035229290801&sdata=CmlEramL%2FHGz745N6HP%2FWRzPwZs0ERh3kQ8%2Bj%2FIUztw%3D&reserved=0 > > -- > > Best regards, > > Jesper Dangaard Brouer > > MSc.CS, Principal Kernel Engineer at Red Hat > > LinkedIn: > > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fbrouer&data=02%7C01%7Csven.auhagen%40voleatech.de%7Ccbd762e5a024488f491b08d863c2b6cb%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637369035229290801&sdata=LJUt38GAkdXS2rW7WG%2BUS0d6eVxZfl3VJqyHvNsqLmY%3D&reserved=0 > > > > _______________________________________________ > Intel-wired-lan mailing list > Intel-wired-lan@osuosl.org > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
WARNING: multiple messages have this Message-ID (diff)
From: Nguyen, Anthony L <anthony.l.nguyen@intel.com> To: intel-wired-lan@osuosl.org Subject: [Intel-wired-lan] bpf_redirect and xdpgeneric Date: Mon, 28 Sep 2020 18:04:14 +0000 [thread overview] Message-ID: <f1a1a7c89fce4ba5c78da65700e02d353bb9e5d4.camel@intel.com> (raw) In-Reply-To: <20200928162010.wpv6ukqscuxaxtnj@svensmacbookair.sven.lan> On Mon, 2020-09-28 at 18:20 +0200, Sven Auhagen wrote: > On Mon, Sep 28, 2020 at 05:24:49PM +0200, Jesper Dangaard Brouer > wrote: > > On Fri, 18 Sep 2020 14:27:45 -0600 > > David Ahern <dsahern@gmail.com> wrote: > > > > > On 9/18/20 12:42 PM, Thomas Ptacek wrote: > > > > The setup is pretty simple. There's an eno1 (igb driver), to > > > > which our > > > > default route points. On the same box are several VMs. There's > > > > a tap > > > > interface (for each VM, call it tapX). Traffic for a VM flows > > > > in from > > > > the Internet on eno1 and is directed to tapX; the response > > > > traffic > > > > flows in the other direction. > > > > > > > > I'm deliberately simplifying here: > > > > > > > > eno1 runs an XDP program that does some lightweight IP > > > > rewriting from > > > > anycast addresses to internal VM addresses on ingress. eno1's > > > > XDP > > > > program currently XDP_PASS's rewritten packets to the IP stack, > > > > where > > > > they're routed to the VM's tap. This works fine. > > > > > > > > tapX runs an XDP program that does the same rewriting in > > > > reverse. > > > > Right now, it also XDP_PASS's packets to the stack, which also > > > > works > > > > --- the stack routes response traffic out eno1. > > > > > > > > I'm playing with XDP_REDIRECT'ing instead of XDP_PASS'ing. > > > > > > > > I have the ifindexes and MAC addresses (and those of IP > > > > neighbors) in > > > > a map --- a normal HASH map, not a DEVMAP. Using that map, I > > > > can > > > > successfully redirect traffic from tapX to arbitrary other tap > > > > interfaces. What I can't do is redirect packets from tapX to > > > > eno1, > > > > which is what the system actually needs to do. > > > > > > > > > > XDP_REDIRECT sends the packet to a devices ndo_xdp_xmit function. > > > tap > > > implements it hence eno1 -> tap works; igb does not meaning tap > > > -> eno1 > > > fails. > > > > There is clearly a real-life use-case for adding native-XDP support > > for > > igb driver. Sven (cc) have implemented this (v6[1]), but something > > is > > causing this patch to not move forward, what is stalling Intel > > maintainers? > > The holdup is from the Intel guys. > There is a v7 with the changes for Kernel 5.9 but it was only posted > on > the Intel list: > > https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20200902203222.185141-1-anthony.l.nguyen at intel.com/ > > They tested it last week so it should hopefully be merged in the next > window. There were some email issues which prevented us from sending it out sooner (after it was tested). The issue was resolved Friday, I just sent the patch to netdev: https://patchwork.ozlabs.org/project/netdev/patch/20200928175908.318502-2-anthony.l.nguyen at intel.com/ Thanks, Tony > > > > To Thomas, you could try out the patch[2] and report back if it > > works > > for you? (I think it will help moving patch forward...) > > > > I would be interested if it works for you as well. > > Best > Sven > > > [1] > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fnetdev%2F20200902054509.23jbv5fyj3otziq2%40svensmacbookair.sven.lan%2F&data=02%7C01%7Csven.auhagen%40voleatech.de%7Ccbd762e5a024488f491b08d863c2b6cb%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637369035229290801&sdata=Pv%2BTEQeY4lcPnIprg0n6K0nHOMMlMo2qlrcmxqWNuLY%3D&reserved=0 > > [2] > > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fnetdev%2Fpatch%2F20200902054509.23jbv5fyj3otziq2%40svensmacbookair.sven.lan%2F&data=02%7C01%7Csven.auhagen%40voleatech.de%7Ccbd762e5a024488f491b08d863c2b6cb%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637369035229290801&sdata=CmlEramL%2FHGz745N6HP%2FWRzPwZs0ERh3kQ8%2Bj%2FIUztw%3D&reserved=0 > > -- > > Best regards, > > Jesper Dangaard Brouer > > MSc.CS, Principal Kernel Engineer at Red Hat > > LinkedIn: > > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fbrouer&data=02%7C01%7Csven.auhagen%40voleatech.de%7Ccbd762e5a024488f491b08d863c2b6cb%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637369035229290801&sdata=LJUt38GAkdXS2rW7WG%2BUS0d6eVxZfl3VJqyHvNsqLmY%3D&reserved=0 > > > > _______________________________________________ > Intel-wired-lan mailing list > Intel-wired-lan at osuosl.org > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
next prev parent reply other threads:[~2020-09-28 18:13 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-18 5:04 bpf_redirect and xdpgeneric Thomas Ptacek 2020-09-18 10:21 ` Toke Høiland-Jørgensen 2020-09-18 18:42 ` Thomas Ptacek 2020-09-18 20:27 ` David Ahern 2020-09-18 20:34 ` Thomas Ptacek 2020-09-28 15:24 ` Jesper Dangaard Brouer 2020-09-28 15:24 ` [Intel-wired-lan] " Jesper Dangaard Brouer 2020-09-28 16:20 ` Sven Auhagen 2020-09-28 16:20 ` [Intel-wired-lan] " Sven Auhagen 2020-09-28 18:04 ` Nguyen, Anthony L [this message] 2020-09-28 18:04 ` Nguyen, Anthony L 2020-09-28 18:14 ` Sven Auhagen 2020-09-28 18:14 ` Sven Auhagen
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=f1a1a7c89fce4ba5c78da65700e02d353bb9e5d4.camel@intel.com \ --to=anthony.l.nguyen@intel.com \ --cc=ThomasPtacek@gmail.com \ --cc=brouer@redhat.com \ --cc=dsahern@gmail.com \ --cc=intel-wired-lan@lists.osuosl.org \ --cc=sven.auhagen@voleatech.de \ --cc=toke@redhat.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.