All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin LaHaise <ben.lahaise@neterion.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [0/14] GRO: Lots of microoptimisations
Date: Thu, 28 May 2009 11:21:43 -0400	[thread overview]
Message-ID: <20090528152143.GA4501@neterion.com> (raw)
In-Reply-To: <20090527230858.GA24278@gondor.apana.org.au>

On Thu, May 28, 2009 at 09:08:58AM +1000, Herbert Xu wrote:
> On Wed, May 27, 2009 at 01:52:23PM -0400, Benjamin LaHaise wrote:
> > 
> > A few questions for you: I've been looking a bit into potential GRO 
> > optimisations that are possible with the vxge driver.  At least from my 
> > existing testing on a P4 Xeon, it seems that doing packet rx via 
> > napi_gro_receive() was a bit slower.  I'll retest with these changes 
> 
> Slower compared to LRO or GRO off?

With GRO off I'm getting ~4.7-5Gbps to the receiver which is CPU bound with 
netperf.  With GRO on, that drops to ~3.9-4.3Gbps.  The only real difference 
is the entry point into the net code being napi_gro_receive() vs 
netif_receive_skb().

> > of yours.  What platform have your tests been run on?  Also, do you have 
> > any notes/ideas on how best to make use of the GRO functionality within 
> > the kernel?  I'm hoping it's possible to make use of a few of the hardware 
> > hints to improve fast path performance.
> 
> What sort of hints do you have?

We have a few bits in the hardware descriptor which indicate if the packet 
is TCP or UDP, IPv4 or IPv6, as well as whether TCP packets are fast path 
eligible.  The hardware can also split up the headers to place the ethernet 
MAC, IP and payload in separate buffers.  I plan to run a few tests to see 
if dispatching directly from the driver into the TCP fast path makes much 
difference.

		-ben

  reply	other threads:[~2009-05-28 15:34 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-27  4:45 [0/14] GRO: Lots of microoptimisations Herbert Xu
2009-05-27  4:50 ` [PATCH 1/14] gro: Open-code frags copy in skb_gro_receive Herbert Xu
2009-05-27  4:50 ` [PATCH 2/14] gro: Inline skb_gro_header and cache frag0 virtual address Herbert Xu
2009-05-27  4:50 ` [PATCH 3/14] gro: Localise offset/headlen in skb_gro_offset Herbert Xu
2009-05-27  4:50 ` [PATCH 4/14] gro: Only use skb_gro_header for completely non-linear packets Herbert Xu
2009-05-27  4:50 ` [PATCH 5/14] tcp: Optimise GRO port comparisons Herbert Xu
2009-05-27  4:50 ` [PATCH 6/14] tcp: Remove unnecessary window comparisons for GRO Herbert Xu
2009-05-27  4:50 ` [PATCH 7/14] tcp: Optimise len/mss comparison Herbert Xu
2009-05-27  4:50 ` [PATCH 8/14] gro: Optimise length comparison in skb_gro_header Herbert Xu
2009-05-27  4:50 ` [PATCH 9/14] gro: Avoid unnecessary comparison after skb_gro_header Herbert Xu
2009-05-27  4:50 ` [PATCH 10/14] ipv4: Use 32-bit loads for ID and length in GRO Herbert Xu
2009-05-27 18:00   ` Andi Kleen
2009-05-27 21:26     ` Herbert Xu
2009-05-27  4:50 ` [PATCH 11/14] gro: Open-code final pskb_may_pull Herbert Xu
2009-05-27  4:50 ` [PATCH 12/14] gro: Nasty optimisations for page frags in skb_gro_receive Herbert Xu
2009-05-27  4:50 ` [PATCH 13/14] gro: Store shinfo in local variable " Herbert Xu
2009-05-27  4:50 ` [PATCH 14/14] tcp: Do not check flush when comparing options for GRO Herbert Xu
2009-05-27 10:42 ` [0/14] GRO: Lots of microoptimisations David Miller
2009-05-27 17:52 ` Benjamin LaHaise
2009-05-27 23:08   ` Herbert Xu
2009-05-28 15:21     ` Benjamin LaHaise [this message]
2009-05-29  9:28       ` Herbert Xu
2009-05-29  9:29         ` Herbert Xu
2009-05-29 16:23           ` Benjamin LaHaise
2009-06-10  5:44             ` Herbert Xu
2009-06-12 16:09               ` Benjamin LaHaise
2009-06-12 23:48                 ` David Miller
2009-06-16 16:35                   ` Benjamin LaHaise
2009-06-16 16:38                     ` Herbert Xu
2009-06-17  8:07                       ` Herbert Xu
2009-06-17  8:08                         ` Herbert Xu
2009-06-17 20:14                           ` Rick Jones

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=20090528152143.GA4501@neterion.com \
    --to=ben.lahaise@neterion.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=netdev@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 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.