Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-18 Thread Alexei Starovoitov
On Tue, Apr 18, 2017 at 11:47:59AM +0200, Johannes Berg wrote: > > I guess any driver that would care about XDP performance would either > > implement in-driver XDP or make sure that skb_linearize() doesn't > > happen in generic XDP by doing build_skb() with the whole packet. > > The driver can be

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-18 Thread Alexei Starovoitov
On Tue, Apr 18, 2017 at 02:46:25PM -0400, David Miller wrote: > From: Alexei Starovoitov > Date: Mon, 17 Apr 2017 16:04:38 -0700 > > > On Mon, Apr 17, 2017 at 03:49:55PM -0400, David Miller wrote: > >> From: Jesper Dangaard Brouer > >> Date: Sun,

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-18 Thread David Miller
From: Alexei Starovoitov Date: Mon, 17 Apr 2017 16:04:38 -0700 > On Mon, Apr 17, 2017 at 03:49:55PM -0400, David Miller wrote: >> From: Jesper Dangaard Brouer >> Date: Sun, 16 Apr 2017 22:26:01 +0200 >> >> > The bpf tail-call use-case is a very

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-18 Thread Johannes Berg
On Fri, 2017-04-14 at 12:41 -0700, Alexei Starovoitov wrote: > > ahh. i thought all drivers do at least copy-break (256) bytes We do copy-break, but that's only applicable when there's no non-linear data left afterwards :) > or copy > get_headlen or build_skb the whole thing. > Since wireless

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-17 Thread Daniel Borkmann
On 04/18/2017 01:04 AM, Alexei Starovoitov wrote: On Mon, Apr 17, 2017 at 03:49:55PM -0400, David Miller wrote: From: Jesper Dangaard Brouer Date: Sun, 16 Apr 2017 22:26:01 +0200 The bpf tail-call use-case is a very good example of why the verifier cannot deduct the needed

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-17 Thread Alexei Starovoitov
On Mon, Apr 17, 2017 at 03:49:55PM -0400, David Miller wrote: > From: Jesper Dangaard Brouer > Date: Sun, 16 Apr 2017 22:26:01 +0200 > > > The bpf tail-call use-case is a very good example of why the > > verifier cannot deduct the needed HEADROOM upfront. > > This brings up a

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-17 Thread David Miller
From: Jesper Dangaard Brouer Date: Sun, 16 Apr 2017 22:26:01 +0200 > The bpf tail-call use-case is a very good example of why the > verifier cannot deduct the needed HEADROOM upfront. This brings up a very interesting question for me. I notice that tail calls are implemented

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-16 Thread Jesper Dangaard Brouer
On Fri, 14 Apr 2017 17:46:44 -0700 Alexei Starovoitov wrote: > But that's probably bad idea, since I was assuming that such ring > reconfiguration can be made fast, which is unlikely. > If it takes seconds to setup a ring, then drivers should just > assume

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-14 Thread Jakub Kicinski
On Fri, 14 Apr 2017 17:46:44 -0700, Alexei Starovoitov wrote: > On Fri, Apr 14, 2017 at 03:30:32PM -0700, Jakub Kicinski wrote: > > On Fri, 14 Apr 2017 12:28:15 -0700, Alexei Starovoitov wrote: > > > On Fri, Apr 14, 2017 at 11:05:25AM +0200, Jesper Dangaard Brouer wrote: > > > > > > > > > >

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-14 Thread Alexei Starovoitov
On Fri, Apr 14, 2017 at 03:30:32PM -0700, Jakub Kicinski wrote: > On Fri, 14 Apr 2017 12:28:15 -0700, Alexei Starovoitov wrote: > > On Fri, Apr 14, 2017 at 11:05:25AM +0200, Jesper Dangaard Brouer wrote: > > > > > > > > We are consistently finding that there is this real need to > > > >

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-14 Thread Jakub Kicinski
On Fri, 14 Apr 2017 12:28:15 -0700, Alexei Starovoitov wrote: > On Fri, Apr 14, 2017 at 11:05:25AM +0200, Jesper Dangaard Brouer wrote: > > > > > > We are consistently finding that there is this real need to > > > communicate XDP capabilities, or somehow verify that the needs > > > of an XDP

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-14 Thread Daniel Borkmann
On 04/14/2017 09:28 PM, Alexei Starovoitov wrote: On Fri, Apr 14, 2017 at 11:05:25AM +0200, Jesper Dangaard Brouer wrote: We are consistently finding that there is this real need to communicate XDP capabilities, or somehow verify that the needs of an XDP program can be satisfied by a given

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-14 Thread Alexei Starovoitov
On Thu, Apr 13, 2017 at 11:38:10AM -0400, David Miller wrote: > From: Johannes Berg > Date: Thu, 13 Apr 2017 08:10:56 +0200 > > > On Wed, 2017-04-12 at 21:20 -0700, Alexei Starovoitov wrote: > > > >> > +if (skb_linearize(skb)) > >> > +goto

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-14 Thread Alexei Starovoitov
On Fri, Apr 14, 2017 at 11:05:25AM +0200, Jesper Dangaard Brouer wrote: > > > > We are consistently finding that there is this real need to > > communicate XDP capabilities, or somehow verify that the needs > > of an XDP program can be satisfied by a given implementation. > > I fully agree that

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-14 Thread Alexei Starovoitov
On Fri, Apr 14, 2017 at 10:07:40AM +0200, Johannes Berg wrote: > On Thu, 2017-04-13 at 16:01 -0400, David Miller wrote: > > From: Johannes Berg > > Date: Thu, 13 Apr 2017 21:22:21 +0200 > > > > > OTOH, it might depend on the frame data itself, if the program does > > >

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-14 Thread Jesper Dangaard Brouer
On Thu, 13 Apr 2017 11:37:22 -0400 (EDT) David Miller wrote: > From: Alexei Starovoitov > Date: Wed, 12 Apr 2017 21:20:38 -0700 > > > On Wed, Apr 12, 2017 at 02:54:15PM -0400, David Miller wrote: [...] > > If the capability is variable, it

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-14 Thread Johannes Berg
On Thu, 2017-04-13 at 16:01 -0400, David Miller wrote: > From: Johannes Berg > Date: Thu, 13 Apr 2017 21:22:21 +0200 > > > OTOH, it might depend on the frame data itself, if the program does > > something like > >  > > xdp->data[xdp->data[0] & 0xf] > >  > > (read or

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-13 Thread David Miller
From: Johannes Berg Date: Thu, 13 Apr 2017 21:22:21 +0200 > OTOH, it might depend on the frame data itself, if the program does > something like > > xdp->data[xdp->data[0] & 0xf] > > (read or write, doesn't really matter) so then the verifier would have > to take the

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-13 Thread Johannes Berg
On Thu, 2017-04-13 at 11:37 -0400, David Miller wrote: > If the capability is variable, it must be communicated to the user > somehow at program load time. > > We are consistently finding that there is this real need to > communicate XDP capabilities, or somehow verify that the needs > of an XDP

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-13 Thread David Miller
From: Daniel Borkmann Date: Thu, 13 Apr 2017 17:57:06 +0200 > On 04/12/2017 08:54 PM, David Miller wrote: > [...] >> +static u32 netif_receive_generic_xdp(struct sk_buff *skb, >> + struct bpf_prog *xdp_prog) >> +{ >> +struct xdp_buff xdp;

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-13 Thread Daniel Borkmann
On 04/12/2017 08:54 PM, David Miller wrote: [...] +static u32 netif_receive_generic_xdp(struct sk_buff *skb, +struct bpf_prog *xdp_prog) +{ + struct xdp_buff xdp; + u32 act = XDP_DROP; + void *orig_data; + int hlen, off; + + if

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-13 Thread David Miller
From: Michael Chan Date: Wed, 12 Apr 2017 23:48:22 -0700 > On Wed, Apr 12, 2017 at 11:54 AM, David Miller wrote: >> >> +static struct static_key generic_xdp_needed __read_mostly; >> + >> +static int generic_xdp_install(struct net_device *dev,

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-13 Thread David Miller
From: Johannes Berg Date: Thu, 13 Apr 2017 08:10:56 +0200 > On Wed, 2017-04-12 at 21:20 -0700, Alexei Starovoitov wrote: > >> > + if (skb_linearize(skb)) >> > + goto do_drop; >> >> when we discussed supporting jumbo frames in XDP, the idea >> was that the

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-13 Thread David Miller
From: Alexei Starovoitov Date: Wed, 12 Apr 2017 21:20:38 -0700 > On Wed, Apr 12, 2017 at 02:54:15PM -0400, David Miller wrote: >> One thing I have not tried to address here is the issue of >> XDP_PACKET_HEADROOM, thanks to Daniel for spotting that. It seems >>

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-13 Thread Michael Chan
On Wed, Apr 12, 2017 at 11:54 AM, David Miller wrote: > > +static struct static_key generic_xdp_needed __read_mostly; > + > +static int generic_xdp_install(struct net_device *dev, struct netdev_xdp > *xdp) > +{ > + struct bpf_prog *new = xdp->prog; > + int ret =

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-13 Thread Johannes Berg
On Wed, 2017-04-12 at 21:20 -0700, Alexei Starovoitov wrote: > > + if (skb_linearize(skb)) > > + goto do_drop; > > when we discussed supporting jumbo frames in XDP, the idea > was that the program would need to look at first 3+k bytes only > and the rest of the packet will be in

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-12 Thread Alexei Starovoitov
On Wed, Apr 12, 2017 at 02:54:15PM -0400, David Miller wrote: > > This provides a generic SKB based non-optimized XDP path which is used > if either the driver lacks a specific XDP implementation, or the user > requests it via a new IFLA_XDP_FLAGS value named XDP_FLAGS_SKB_MODE. > > It is

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-12 Thread David Ahern
On 4/12/17 8:08 PM, David Miller wrote: > From: David Ahern > Date: Wed, 12 Apr 2017 13:54:20 -0600 > >> packet passed to xdp seems to be messed up > Ok, the problem is that skb->mac_len isn't set properly at this point. > That doesn't happen until

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-12 Thread David Miller
From: David Ahern Date: Wed, 12 Apr 2017 13:54:20 -0600 > packet passed to xdp seems to be messed up Ok, the problem is that skb->mac_len isn't set properly at this point. That doesn't happen until __netif_receive_skb_core(). I'm also not setting xdp.data_hard_start

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-12 Thread David Miller
From: Stephen Hemminger Date: Wed, 12 Apr 2017 14:30:37 -0700 > On Wed, 12 Apr 2017 14:54:15 -0400 (EDT) > David Miller wrote: > >> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h >> index b0aa089..071a58b 100644 >> ---

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-12 Thread David Miller
From: Eric Dumazet Date: Wed, 12 Apr 2017 14:49:53 -0700 > On Wed, 2017-04-12 at 14:30 -0700, Stephen Hemminger wrote: >> On Wed, 12 Apr 2017 14:54:15 -0400 (EDT) >> David Miller wrote: >> >> > diff --git a/include/linux/netdevice.h

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-12 Thread Eric Dumazet
On Wed, 2017-04-12 at 14:30 -0700, Stephen Hemminger wrote: > On Wed, 12 Apr 2017 14:54:15 -0400 (EDT) > David Miller wrote: > > > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h > > index b0aa089..071a58b 100644 > > --- a/include/linux/netdevice.h > > +++

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-12 Thread Stephen Hemminger
On Wed, 12 Apr 2017 14:54:15 -0400 (EDT) David Miller wrote: > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h > index b0aa089..071a58b 100644 > --- a/include/linux/netdevice.h > +++ b/include/linux/netdevice.h > @@ -1891,9 +1891,17 @@ struct net_device {

Re: [PATCH v3 net-next RFC] Generic XDP

2017-04-12 Thread David Ahern
On 4/12/17 12:54 PM, David Miller wrote: > > This provides a generic SKB based non-optimized XDP path which is used > if either the driver lacks a specific XDP implementation, or the user > requests it via a new IFLA_XDP_FLAGS value named XDP_FLAGS_SKB_MODE. > > It is arguable that perhaps I

[PATCH v3 net-next RFC] Generic XDP

2017-04-12 Thread David Miller
This provides a generic SKB based non-optimized XDP path which is used if either the driver lacks a specific XDP implementation, or the user requests it via a new IFLA_XDP_FLAGS value named XDP_FLAGS_SKB_MODE. It is arguable that perhaps I should have required something like this as part of the