All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Tom Herbert <tom@herbertland.com>
Cc: Thomas Graf <tgraf@suug.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>,
	Kernel Team <kernel-team@fb.com>,
	Tariq Toukan <tariqt@mellanox.com>,
	Brenden Blanco <bblanco@plumgrid.com>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	brouer@redhat.com
Subject: Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP
Date: Wed, 21 Sep 2016 21:56:58 +0200	[thread overview]
Message-ID: <20160921215658.2c61ed5e@redhat.com> (raw)
In-Reply-To: <CALx6S36ZCdh5iOp6CPfztVKOEkDFgUo1RyqWMJVxhakOYNx8iw@mail.gmail.com>


On Wed, 21 Sep 2016 08:08:34 -0700 Tom Herbert <tom@herbertland.com> wrote:

> On Wed, Sep 21, 2016 at 7:48 AM, Thomas Graf <tgraf@suug.ch> wrote:
> > On 09/21/16 at 07:19am, Tom Herbert wrote:  
> >> certain design that because of constraints on one kernel interface. As
> >> a kernel developer I want flexibility on how we design and implement
> >> things!  
> >
> > Perfectly valid argument. I reviewed your ILA changes and did not
> > object to them.
> >
> >  
> >> I think there are two questions that this patch set poses for the
> >> community wrt XDP:
> >>
> >> #1: Should we allow alternate code to run in XDP other than BPF?
> >> #2: If #1 is true what is the best way to implement that?
> >>
> >> If the answer to #1 is "no" then the answer to #2 is irrelevant. So
> >> with this RFC I'm hoping we can come the agreement on questions #1.  

I vote yes to #1.

> > I'm not opposed to running non-BPF code at XDP. I'm against adding
> > a linked list of hook consumers.

I also worry about the performance impact of a linked list.  We should
simple benchmark it instead of discussing it! ;-)


> > Would anyone require to run XDP-BPF in combination ILA? Or XDP-BPF
> > in combination with a potential XDP-nftables? We don't know yet I
> > guess.
> >  
> Right. Admittedly, I feel like we owe a bit of reciprocity to
> nftables. For ILA we are using the NF_INET_PRE_ROUTING hook with our
> own code (looks like ipvlan set nfhooks as well). This works really
> well and saves the value of early demux in ILA. Had we not had the
> ability to use nfhooks in this fashion it's likely we would have had
> to create another hook (we did try putting translation in nftables
> rules but that was too inefficient for ILA).

Thinking about it, I actually think Tom is proposing a very valid user
of the XDP hook, which is the kernel itself.  And Tom even have a real
first user ILA.  The way I read the ILA-RFC-draft[1], the XDP hook
would benefit the NVE (Network Virtualization Edge) component, which
can run separately or run on the Tenant System, where the latter case
could use XDP_PASS.

[1] https://www.ietf.org/archive/id/draft-herbert-nvo3-ila-02.txt
-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer

  reply	other threads:[~2016-09-21 19:57 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-20 22:00 [PATCH RFC 0/3] xdp: Generalize XDP Tom Herbert
2016-09-20 22:00 ` [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP Tom Herbert
2016-09-20 22:37   ` Eric Dumazet
2016-09-20 22:40     ` Tom Herbert
2016-09-20 22:44   ` Thomas Graf
2016-09-20 22:49     ` Tom Herbert
2016-09-20 23:09       ` Thomas Graf
2016-09-20 23:18         ` Tom Herbert
2016-09-20 23:43           ` Thomas Graf
2016-09-20 23:59             ` Tom Herbert
2016-09-21  0:13               ` Alexei Starovoitov
2016-09-21 11:55               ` Thomas Graf
2016-09-21 14:19                 ` Tom Herbert
2016-09-21 14:48                   ` Thomas Graf
2016-09-21 15:08                     ` Tom Herbert
2016-09-21 19:56                       ` Jesper Dangaard Brouer [this message]
2016-09-22 13:14                         ` Jesper Dangaard Brouer
2016-09-22 14:46                           ` Eric Dumazet
2016-09-21 15:39                   ` Alexei Starovoitov
2016-09-21 17:26                 ` Jakub Kicinski
2016-09-20 23:22         ` Daniel Borkmann
2016-09-21  0:01   ` Alexei Starovoitov
2016-09-21  6:39     ` Jesper Dangaard Brouer
2016-09-21  8:42       ` Daniel Borkmann
2016-09-21 15:44       ` Alexei Starovoitov
2016-09-21 17:26     ` Jakub Kicinski
2016-09-21 17:39       ` Tom Herbert
2016-09-21 18:45         ` Jakub Kicinski
2016-09-21 18:50           ` Tom Herbert
2016-09-21 18:54             ` Jakub Kicinski
2016-09-21 18:58             ` Thomas Graf
2016-09-23 11:13   ` Jamal Hadi Salim
2016-09-23 13:00     ` Jesper Dangaard Brouer
2016-09-23 14:26       ` Alexei Starovoitov
2016-09-25 11:32       ` Jamal Hadi Salim
2016-09-23 14:14     ` Tom Herbert
2016-09-25 12:29       ` Jamal Hadi Salim
2016-09-20 22:00 ` [PATCH RFC 2/3] mlx4: Change XDP/BPF to use generic XDP infrastructure Tom Herbert
2016-09-20 22:00 ` [PATCH RFC 3/3] netdevice: Remove obsolete xdp_netdev_command Tom Herbert

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=20160921215658.2c61ed5e@redhat.com \
    --to=brouer@redhat.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bblanco@plumgrid.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=kernel-team@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=tariqt@mellanox.com \
    --cc=tgraf@suug.ch \
    --cc=tom@herbertland.com \
    /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.