On Sun, 2017-04-09 at 13:35 -0700, David Miller wrote:
> This provides a generic non-optimized XDP implementation when the
> device driver does not provide an optimized one.
>
> It is arguable that perhaps I should have required something like
> this as part of the initial XDP feature merge.
>
>
On Tue, 2017-04-11 at 09:05 -0700, Eric Dumazet wrote:
> Some kind of copybreak maybe ?
>
> perf record -a -g sleep 5
> perf report --stdio
>
> Copybreak is generally not really useful, and can have downsides.
>
> Much better to let upper stacks deciding this.
>
> For example, there is no poin
On Mon, 2017-04-10 at 17:41 -0400, Andy Gospodarek wrote:
> Results with bpf_git_enable=1 and gro off, still only 7.5Mpps.
7.5 Mpps is already a nice number.
We all understand that using native XDP in the driver might give some
extra pps, but for the ones that do not want to patch old drivers, i
From: Michael Chan
Date: Mon, 10 Apr 2017 14:47:04 -0700
> On Mon, Apr 10, 2017 at 2:30 PM, Andy Gospodarek wrote:
>> On Mon, Apr 10, 2017 at 03:28:54PM -0400, David Miller wrote:
>>> From: Andy Gospodarek
>>> Date: Mon, 10 Apr 2017 14:39:35 -0400
>>>
>>> > As promised, I did some testing today
On Mon, Apr 10, 2017 at 2:30 PM, Andy Gospodarek wrote:
> On Mon, Apr 10, 2017 at 03:28:54PM -0400, David Miller wrote:
>> From: Andy Gospodarek
>> Date: Mon, 10 Apr 2017 14:39:35 -0400
>>
>> > As promised, I did some testing today with bnxt_en's implementation
>> > of XDP and this one.
>>
>> Tha
On Mon, Apr 10, 2017 at 10:12:42PM +0200, Daniel Borkmann wrote:
> On 04/10/2017 08:39 PM, Andy Gospodarek wrote:
> [...]
> > I ran this on a desktop-class system I have (i7-6700 CPU @ 3.40GHz)
> > and used pktgen_sample03_burst_single_flow.sh from another system to
> > throw ~6.5Mpps as a single U
On Mon, Apr 10, 2017 at 03:34:56PM -0400, David Miller wrote:
> From: Andy Gospodarek
> Date: Mon, 10 Apr 2017 14:39:35 -0400
>
> > I also noted that...
> >
> > xdp1 not parsing the protocol correctly. All traffic was showing up as
> > protocol '0' instead of '17' in the output.
> >
> > xdp
On Mon, Apr 10, 2017 at 03:28:54PM -0400, David Miller wrote:
> From: Andy Gospodarek
> Date: Mon, 10 Apr 2017 14:39:35 -0400
>
> > As promised, I did some testing today with bnxt_en's implementation
> > of XDP and this one.
>
> Thanks a lot Andy, obviously the patch needs some more work.
>
> I
On 04/09/2017 10:35 PM, David Miller wrote:
[...]
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index cc07c3b..f8ff49c 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1892,6 +1892,7 @@ struct net_device {
struct lock_class_key *qdisc_tx_bu
On 04/10/2017 08:39 PM, Andy Gospodarek wrote:
[...]
I ran this on a desktop-class system I have (i7-6700 CPU @ 3.40GHz)
and used pktgen_sample03_burst_single_flow.sh from another system to
throw ~6.5Mpps as a single UDP stream towards the system running XDP.
I just commented out the ndo_xdp op
On 04/10/2017 04:18 AM, Alexei Starovoitov wrote:
[...]
+ xdp.data_end = xdp.data + hlen;
+ xdp.data_hard_start = xdp.data - skb_headroom(skb);
+ orig_data = xdp.data;
+ act = bpf_prog_run_xdp(xdp_prog, &xdp);
+
+ off = xdp.data - orig_data;
+ if (off)
+
From: Andy Gospodarek
Date: Mon, 10 Apr 2017 14:39:35 -0400
> I also noted that...
>
> xdp1 not parsing the protocol correctly. All traffic was showing up as
> protocol '0' instead of '17' in the output.
>
> xdp2 was not actually sending the frames back out when using this patch.
>
> I'll
From: Alexei Starovoitov
Date: Sun, 9 Apr 2017 19:18:09 -0700
> On Sun, Apr 09, 2017 at 01:35:28PM -0700, David Miller wrote:
>> +if (skb_linearize(skb))
>> +goto do_drop;
>
> do we need to force disable gro ?
I think we do.
> Otherwise if we linearize skb_is_gso packet it will
From: Andy Gospodarek
Date: Mon, 10 Apr 2017 14:39:35 -0400
> As promised, I did some testing today with bnxt_en's implementation
> of XDP and this one.
Thanks a lot Andy, obviously the patch needs some more work.
I noticed GRO stuff in your profile, and Alexei mentioned this earlier
today. We
On Sun, 09 Apr 2017 13:35:28 -0700 (PDT)
David Miller wrote:
> This provides a generic non-optimized XDP implementation when the
> device driver does not provide an optimized one.
>
> It is arguable that perhaps I should have required something like
> this as part of the initial XDP feature merg
On Sun, Apr 09, 2017 at 01:35:28PM -0700, David Miller wrote:
>
> This provides a generic non-optimized XDP implementation when the
> device driver does not provide an optimized one.
>
> It is arguable that perhaps I should have required something like
> this as part of the initial XDP feature me
>> static int netif_receive_skb_internal(struct sk_buff *skb)
>> {
>> int ret;
>> @@ -4258,6 +4336,21 @@ static int netif_receive_skb_internal(struct sk_buff
>> *skb)
>>
>> rcu_read_lock();
>>
>> + if (static_key_false(&generic_xdp_needed)) {
>> + struct bpf_prog *xdp
On Sun, Apr 09, 2017 at 01:35:28PM -0700, David Miller wrote:
>
> This provides a generic non-optimized XDP implementation when the
> device driver does not provide an optimized one.
>
> It is arguable that perhaps I should have required something like
> this as part of the initial XDP feature me
This provides a generic non-optimized XDP implementation when the
device driver does not provide an optimized one.
It is arguable that perhaps I should have required something like
this as part of the initial XDP feature merge.
I believe this is critical for two reasons:
1) Accessibility. More
19 matches
Mail list logo
