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
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, 16 Apr 2017 22:26:01 +0200
> >>
> >> > The bpf t
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 good example of why the
>> > verifier cannot deduc
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
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 HEADROOM upfront.
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 very interesting qu
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 by JITs largely by
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 XDP_PACKET_HEADROOM, since at that time
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:
> > > > >
> > > > > We
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
> > > > communicat
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 progr
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 impl
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 do_drop;
> >>
> >> when we disc
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 w
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
> > > something like
> > >
> > >
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 must be communicated to the user
> somehow at progra
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 write, doesn't really matter)
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 maximum possible value ther
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
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;
>> +u32 act = XDP_
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 (sk
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, struct netdev_xdp
>> *xdp)
>> +{
>> + struct b
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 program would need to look at
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
>> incredibly expensive to do a skb_co
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 = 0;
> +
> + switc
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 non-c
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 arguabl
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 __netif_receive_skb_core().
>
> I'm also not se
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 properly.
It should work be
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
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netde
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 b/include/linux/netdevice.h
>> > index b0aa089..071a58b 100644
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
> > +++ b/include/linux/netde
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 {
> struct lock_cl
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 shou
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 i
35 matches
Mail list logo
