From: Sven Auhagen <sven.auhagen@voleatech.de>
To: "Nguyen, Anthony L" <anthony.l.nguyen@intel.com>
Cc: "brouer@redhat.com" <brouer@redhat.com>,
"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 20:14:33 +0200 [thread overview]
Message-ID: <20200928181433.v6bc5z4hza24es2c@svensmacbookair.sven.lan> (raw)
In-Reply-To: <f1a1a7c89fce4ba5c78da65700e02d353bb9e5d4.camel@intel.com>
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@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
prev parent reply other threads:[~2020-09-28 18:14 UTC|newest]
Thread overview: 9+ 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 16:20 ` Sven Auhagen
2020-09-28 18:04 ` [Intel-wired-lan] " Nguyen, Anthony L
2020-09-28 18:14 ` Sven Auhagen [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=20200928181433.v6bc5z4hza24es2c@svensmacbookair.sven.lan \
--to=sven.auhagen@voleatech.de \
--cc=ThomasPtacek@gmail.com \
--cc=anthony.l.nguyen@intel.com \
--cc=brouer@redhat.com \
--cc=dsahern@gmail.com \
--cc=intel-wired-lan@lists.osuosl.org \
--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: 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).