* [Intel-wired-lan] bpf_redirect and xdpgeneric [not found] ` <5f7f5056-d1de-737b-2d76-cd37e4a4db8e@gmail.com> @ 2020-09-28 15:24 ` Jesper Dangaard Brouer 2020-09-28 16:20 ` Sven Auhagen 0 siblings, 1 reply; 4+ messages in thread From: Jesper Dangaard Brouer @ 2020-09-28 15:24 UTC (permalink / raw) To: intel-wired-lan 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? 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...) [1] https://lore.kernel.org/netdev/20200902054509.23jbv5fyj3otziq2 at svensmacbookair.sven.lan/ [2] http://patchwork.ozlabs.org/project/netdev/patch/20200902054509.23jbv5fyj3otziq2 at svensmacbookair.sven.lan/ -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Intel-wired-lan] bpf_redirect and xdpgeneric 2020-09-28 15:24 ` [Intel-wired-lan] bpf_redirect and xdpgeneric Jesper Dangaard Brouer @ 2020-09-28 16:20 ` Sven Auhagen 2020-09-28 18:04 ` Nguyen, Anthony L 0 siblings, 1 reply; 4+ messages in thread From: Sven Auhagen @ 2020-09-28 16:20 UTC (permalink / raw) To: intel-wired-lan 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. > > 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 > ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Intel-wired-lan] bpf_redirect and xdpgeneric 2020-09-28 16:20 ` Sven Auhagen @ 2020-09-28 18:04 ` Nguyen, Anthony L 2020-09-28 18:14 ` Sven Auhagen 0 siblings, 1 reply; 4+ messages in thread From: Nguyen, Anthony L @ 2020-09-28 18:04 UTC (permalink / raw) To: intel-wired-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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Intel-wired-lan] bpf_redirect and xdpgeneric 2020-09-28 18:04 ` Nguyen, Anthony L @ 2020-09-28 18:14 ` Sven Auhagen 0 siblings, 0 replies; 4+ messages in thread From: Sven Auhagen @ 2020-09-28 18:14 UTC (permalink / raw) To: intel-wired-lan On Mon, Sep 28, 2020 at 06:04:14PM +0000, Nguyen, Anthony L wrote: > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fintel-wired-lan%2Fpatch%2F20200902203222.185141-1-anthony.l.nguyen%40intel.com%2F&data=02%7C01%7Csven.auhagen%40voleatech.de%7Ce8e80921128f4ac3edac08d863d8f03f%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637369130683150522&sdata=d1BsVNZlbp7Kgh8bmzailbrR22Y61%2B6mb0VdKtK30yw%3D&reserved=0 > > > > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fnetdev%2Fpatch%2F20200928175908.318502-2-anthony.l.nguyen%40intel.com%2F&data=02%7C01%7Csven.auhagen%40voleatech.de%7Ce8e80921128f4ac3edac08d863d8f03f%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637369130683160513&sdata=4h1AykO8YnnPSvulMtqeKZnjJ5DFOV1ISnd3OrFCOow%3D&reserved=0 > > Thanks, > Tony Thank you Tony! Best Sven > > > > > > > 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%7Ce8e80921128f4ac3edac08d863d8f03f%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637369130683160513&sdata=isaa7n1ZQ780i4qBS4%2FcyY2jcH8hNGpcdM1k9C%2FREBw%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%7Ce8e80921128f4ac3edac08d863d8f03f%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637369130683160513&sdata=FgceLkpqx8G456QFYfd9NtyzB0nR1Pah7xWtaYLs6ho%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%7Ce8e80921128f4ac3edac08d863d8f03f%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637369130683160513&sdata=sSXuQu60fdu%2BbDMmJburEkEllprEuSXdb8n1L02FPNk%3D&reserved=0 > > > > > > > _______________________________________________ > > Intel-wired-lan mailing list > > Intel-wired-lan at osuosl.org > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osuosl.org%2Fmailman%2Flistinfo%2Fintel-wired-lan&data=02%7C01%7Csven.auhagen%40voleatech.de%7Ce8e80921128f4ac3edac08d863d8f03f%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637369130683160513&sdata=Rgn71oeQEuNQ9jlX1bSnbcxiZnmAP3YBGM9GfbC1x94%3D&reserved=0 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-09-28 18:14 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CANDGNvbX+BwA_ZUmw2rxH5FGLFsCVH33Tw3RCk3e3Qo69J+4qw@mail.gmail.com>
[not found] ` <87lfh7fkqs.fsf@toke.dk>
[not found] ` <CANDGNvbY=8XEJP=S3e+5V2RU6u0zjRE3YDo62bhV-Qaje=++2A@mail.gmail.com>
[not found] ` <5f7f5056-d1de-737b-2d76-cd37e4a4db8e@gmail.com>
2020-09-28 15:24 ` [Intel-wired-lan] bpf_redirect and xdpgeneric Jesper Dangaard Brouer
2020-09-28 16:20 ` Sven Auhagen
2020-09-28 18:04 ` Nguyen, Anthony L
2020-09-28 18:14 ` Sven Auhagen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox