All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] bpf_redirect and xdpgeneric
Date: Mon, 28 Sep 2020 17:24:49 +0200	[thread overview]
Message-ID: <20200928172449.50a3e755@carbon> (raw)
In-Reply-To: <5f7f5056-d1de-737b-2d76-cd37e4a4db8e@gmail.com>

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


WARNING: multiple messages have this Message-ID (diff)
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: David Ahern <dsahern@gmail.com>,
	Sven Auhagen <sven.auhagen@voleatech.de>,
	Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	intel-wired-lan@lists.osuosl.org
Cc: brouer@redhat.com, ThomasPtacek@gmail.com,
	"Toke Høiland-Jørgensen" <toke@redhat.com>,
	xdp-newbies@vger.kernel.org
Subject: Re: bpf_redirect and xdpgeneric
Date: Mon, 28 Sep 2020 17:24:49 +0200	[thread overview]
Message-ID: <20200928172449.50a3e755@carbon> (raw)
In-Reply-To: <5f7f5056-d1de-737b-2d76-cd37e4a4db8e@gmail.com>

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@svensmacbookair.sven.lan/
[2] http://patchwork.ozlabs.org/project/netdev/patch/20200902054509.23jbv5fyj3otziq2@svensmacbookair.sven.lan/
-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer


  parent reply	other threads:[~2020-09-28 15:24 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 [this message]
2020-09-28 15:24         ` Jesper Dangaard Brouer
2020-09-28 16:20         ` [Intel-wired-lan] " Sven Auhagen
2020-09-28 16:20           ` Sven Auhagen
2020-09-28 18:04           ` [Intel-wired-lan] " Nguyen, Anthony L
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=20200928172449.50a3e755@carbon \
    --to=brouer@redhat.com \
    --cc=intel-wired-lan@osuosl.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 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.