netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Andy Gospodarek <andy@greyhouse.net>
Cc: David Miller <davem@davemloft.net>,
	michael.chan@broadcom.com, netdev@vger.kernel.org,
	xdp-newbies@vger.kernel.org
Subject: Re: [PATCH v4 net-next RFC] net: Generic XDP
Date: Wed, 19 Apr 2017 10:44:59 -0700	[thread overview]
Message-ID: <58F7A21B.9060309@gmail.com> (raw)
In-Reply-To: <20170419171753.GA12838@ast-mbp.thefacebook.com>

On 17-04-19 10:17 AM, Alexei Starovoitov wrote:
> On Wed, Apr 19, 2017 at 10:29:03AM -0400, Andy Gospodarek wrote:
>>
>> I ran this on top of a card that uses the bnxt_en driver on a desktop
>> class system with an i7-6700 CPU @ 3.40GHz, sending a single stream of
>> UDP traffic with flow control disabled and saw the following (all stats
>> in Million PPS).
>>
>>                 xdp1                xdp2            xdp_tx_tunnel
>> Generic XDP      7.8    5.5 (1.3 actual)         4.6 (1.1 actual)
>> Optimized XDP   11.7		     9.7                      4.6
> 
> Nice! Thanks for testing.
> 
>> One thing to note is that the Generic XDP case shows some different
>> results for reported by the application vs actual (seen on the wire).  I
>> did not debug where the drops are happening and what counter needs to be
>> incremented to note this -- I'll add that to my TODO list.  The
>> Optimized XDP case does not have a difference in reported vs actual
>> frames on the wire.
> 
> The missed packets are probably due to xmit queue being full.
> We need 'xdp_tx_full' counter in:
> +       if (free_skb) {
> +               trace_xdp_exception(dev, xdp_prog, XDP_TX);
> +               kfree_skb(skb);
> +       }
> like in-driver xdp does.
> It's surprising that tx becomes full so often. May be bnxt specific behavior?

hmm as a data point I get better numbers than 1.3Mpps running through the qdisc
layer with pktgen so seems like something is wrong with the driver perhaps? If
I get a chance I'll take a look with my setup here, although it likely wont be
until the weekend. I don't think it needs to slow down dropping the RFC tag
and getting the patch applied though.

> 
>> I agree with all those who have asserted that this is great tool for
>> those that want to get started with XDP but do not have hardware, so I'd
>> say it's ready to have the 'RFC' tag dropped.  Thanks for pushing this
>> forward, Dave!  :-)
> 
> +1
>  
> 

  reply	other threads:[~2017-04-19 17:45 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-13 16:09 [PATCH v4 net-next RFC] net: Generic XDP David Miller
2017-04-13 20:16 ` Michael Chan
2017-04-13 20:23   ` David Miller
2017-04-14  1:59     ` [lkp-robot] [net] d1dff7db3b: net/core/dev.c:#suspicious_rcu_dereference_check()usage kernel test robot
2017-04-15  0:59     ` [PATCH v4 net-next RFC] net: Generic XDP Alexei Starovoitov
2017-04-15 15:46       ` David Ahern
2017-04-18 19:05       ` Andy Gospodarek
2017-04-18 19:07         ` David Miller
2017-04-18 19:29           ` David Miller
2017-04-18 19:37             ` Andy Gospodarek
2017-04-19 14:29             ` Andy Gospodarek
2017-04-19 17:17               ` Alexei Starovoitov
2017-04-19 17:44                 ` John Fastabend [this message]
2017-04-19 20:25                   ` Andy Gospodarek
2017-04-20  0:13                     ` Alexei Starovoitov
2017-04-20  1:40               ` David Miller
2017-04-20 22:09                 ` Andy Gospodarek
2017-04-20 14:30               ` Jesper Dangaard Brouer
2017-04-24 13:18                 ` Jesper Dangaard Brouer
2017-04-18 20:26         ` Jesper Dangaard Brouer
2017-04-14 16:33 ` William Tu
2017-04-24 14:24 ` Blogpost evaluation this " Jesper Dangaard Brouer
2017-04-24 22:26   ` David Miller
2017-04-25  8:28     ` Jesper Dangaard Brouer
2017-04-25 17:25     ` Andy Gospodarek
2017-04-25 17:31       ` David Miller

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=58F7A21B.9060309@gmail.com \
    --to=john.fastabend@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andy@greyhouse.net \
    --cc=davem@davemloft.net \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=xdp-newbies@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).