All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>, Jason Cooper <jason@lakedaemon.net>,
	linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Soeren Moch <smoch@web.de>, Paul Mackerras <paulus@samba.org>,
	linux-arm-kernel@lists.infradead.org,
	Dale Farnsworth <dale@farnsworth.org>,
	netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	Florian Fainelli <florian@openwrt.org>,
	Lennert Buytenhek <buytenh@wantstofly.org>,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Subject: Re: [PATCH] net: mv643xx_eth: Add GRO support
Date: Thu, 11 Apr 2013 18:02:58 +0200	[thread overview]
Message-ID: <20130411160258.GI1910@1wt.eu> (raw)
In-Reply-To: <1365695675.3887.165.camel@edumazet-glaptop>

On Thu, Apr 11, 2013 at 08:54:35AM -0700, Eric Dumazet wrote:
> On Thu, 2013-04-11 at 17:32 +0200, Willy Tarreau wrote:
> > On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
> > > I don't have a strong opinion on whether Soeren's or your proposal should
> > > be submitted. But I insist on having one of them in, as GRO significantly
> > > improves the common use case, is enabled by default, and not as
> > > constrained as LRO.
> > 
> > I agree, use yours first, but we should keep an eye on this. Since you have
> > everything to run a test, please try to see if you can get netperf to run
> > over IPv6, I'm sure the NIC doesn't handle it.
> 
> Willy, testing the checksum in the NIC driver itself prevents the stack
> doing GRO even if the NIC could not checksum the packet, as in GRE
> tunneling for example.
> 
> So Sebastien patch is better IMHO : Just call the napi gro handler and
> let core stack handles the details ;)

OK, that makes sense indeed, I didn't think about this case. All
I remember was that the old call achieved a higher packet rate
than napi_gro_receive, but it was on an older kernel and I can't
be more specifics after several months :-/

Cheers,
Willy

WARNING: multiple messages have this Message-ID (diff)
From: w@1wt.eu (Willy Tarreau)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] net: mv643xx_eth: Add GRO support
Date: Thu, 11 Apr 2013 18:02:58 +0200	[thread overview]
Message-ID: <20130411160258.GI1910@1wt.eu> (raw)
In-Reply-To: <1365695675.3887.165.camel@edumazet-glaptop>

On Thu, Apr 11, 2013 at 08:54:35AM -0700, Eric Dumazet wrote:
> On Thu, 2013-04-11 at 17:32 +0200, Willy Tarreau wrote:
> > On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
> > > I don't have a strong opinion on whether Soeren's or your proposal should
> > > be submitted. But I insist on having one of them in, as GRO significantly
> > > improves the common use case, is enabled by default, and not as
> > > constrained as LRO.
> > 
> > I agree, use yours first, but we should keep an eye on this. Since you have
> > everything to run a test, please try to see if you can get netperf to run
> > over IPv6, I'm sure the NIC doesn't handle it.
> 
> Willy, testing the checksum in the NIC driver itself prevents the stack
> doing GRO even if the NIC could not checksum the packet, as in GRE
> tunneling for example.
> 
> So Sebastien patch is better IMHO : Just call the napi gro handler and
> let core stack handles the details ;)

OK, that makes sense indeed, I didn't think about this case. All
I remember was that the old call achieved a higher packet rate
than napi_gro_receive, but it was on an older kernel and I can't
be more specifics after several months :-/

Cheers,
Willy

WARNING: multiple messages have this Message-ID (diff)
From: Willy Tarreau <w@1wt.eu>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
	Andrew Lunn <andrew@lunn.ch>, Jason Cooper <jason@lakedaemon.net>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	linux-kernel@vger.kernel.org,
	Florian Fainelli <florian@openwrt.org>,
	Soeren Moch <smoch@web.de>, Paul Mackerras <paulus@samba.org>,
	Lennert Buytenhek <buytenh@wantstofly.org>,
	Dale Farnsworth <dale@farnsworth.org>,
	netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	"David S. Miller" <davem@davemloft.net>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] net: mv643xx_eth: Add GRO support
Date: Thu, 11 Apr 2013 18:02:58 +0200	[thread overview]
Message-ID: <20130411160258.GI1910@1wt.eu> (raw)
In-Reply-To: <1365695675.3887.165.camel@edumazet-glaptop>

On Thu, Apr 11, 2013 at 08:54:35AM -0700, Eric Dumazet wrote:
> On Thu, 2013-04-11 at 17:32 +0200, Willy Tarreau wrote:
> > On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
> > > I don't have a strong opinion on whether Soeren's or your proposal should
> > > be submitted. But I insist on having one of them in, as GRO significantly
> > > improves the common use case, is enabled by default, and not as
> > > constrained as LRO.
> > 
> > I agree, use yours first, but we should keep an eye on this. Since you have
> > everything to run a test, please try to see if you can get netperf to run
> > over IPv6, I'm sure the NIC doesn't handle it.
> 
> Willy, testing the checksum in the NIC driver itself prevents the stack
> doing GRO even if the NIC could not checksum the packet, as in GRE
> tunneling for example.
> 
> So Sebastien patch is better IMHO : Just call the napi gro handler and
> let core stack handles the details ;)

OK, that makes sense indeed, I didn't think about this case. All
I remember was that the old call achieved a higher packet rate
than napi_gro_receive, but it was on an older kernel and I can't
be more specifics after several months :-/

Cheers,
Willy


WARNING: multiple messages have this Message-ID (diff)
From: Willy Tarreau <w@1wt.eu>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>, Jason Cooper <jason@lakedaemon.net>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Soeren Moch <smoch@web.de>, Paul Mackerras <paulus@samba.org>,
	linux-arm-kernel@lists.infradead.org,
	Dale Farnsworth <dale@farnsworth.org>,
	netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	Florian Fainelli <florian@openwrt.org>,
	Lennert Buytenhek <buytenh@wantstofly.org>,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Subject: Re: [PATCH] net: mv643xx_eth: Add GRO support
Date: Thu, 11 Apr 2013 18:02:58 +0200	[thread overview]
Message-ID: <20130411160258.GI1910@1wt.eu> (raw)
In-Reply-To: <1365695675.3887.165.camel@edumazet-glaptop>

On Thu, Apr 11, 2013 at 08:54:35AM -0700, Eric Dumazet wrote:
> On Thu, 2013-04-11 at 17:32 +0200, Willy Tarreau wrote:
> > On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
> > > I don't have a strong opinion on whether Soeren's or your proposal should
> > > be submitted. But I insist on having one of them in, as GRO significantly
> > > improves the common use case, is enabled by default, and not as
> > > constrained as LRO.
> > 
> > I agree, use yours first, but we should keep an eye on this. Since you have
> > everything to run a test, please try to see if you can get netperf to run
> > over IPv6, I'm sure the NIC doesn't handle it.
> 
> Willy, testing the checksum in the NIC driver itself prevents the stack
> doing GRO even if the NIC could not checksum the packet, as in GRE
> tunneling for example.
> 
> So Sebastien patch is better IMHO : Just call the napi gro handler and
> let core stack handles the details ;)

OK, that makes sense indeed, I didn't think about this case. All
I remember was that the old call achieved a higher packet rate
than napi_gro_receive, but it was on an older kernel and I can't
be more specifics after several months :-/

Cheers,
Willy

  reply	other threads:[~2013-04-11 16:03 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-11 12:40 [PATCH] net: mv643xx_eth: Add GRO support Sebastian Hesselbarth
2013-04-11 12:40 ` Sebastian Hesselbarth
2013-04-11 12:40 ` Sebastian Hesselbarth
2013-04-11 13:13 ` Willy Tarreau
2013-04-11 13:13   ` Willy Tarreau
2013-04-11 13:13   ` Willy Tarreau
2013-04-11 13:13   ` Willy Tarreau
2013-04-11 14:47   ` Sebastian Hesselbarth
2013-04-11 14:47     ` Sebastian Hesselbarth
2013-04-11 14:47     ` Sebastian Hesselbarth
2013-04-11 15:03     ` Willy Tarreau
2013-04-11 15:03       ` Willy Tarreau
2013-04-11 15:03       ` Willy Tarreau
2013-04-11 15:03       ` Willy Tarreau
2013-04-11 15:27       ` Sebastian Hesselbarth
2013-04-11 15:27         ` Sebastian Hesselbarth
2013-04-11 15:27         ` Sebastian Hesselbarth
2013-04-11 15:32         ` Willy Tarreau
2013-04-11 15:32           ` Willy Tarreau
2013-04-11 15:32           ` Willy Tarreau
2013-04-11 15:32           ` Willy Tarreau
2013-04-11 15:54           ` Eric Dumazet
2013-04-11 15:54             ` Eric Dumazet
2013-04-11 15:54             ` Eric Dumazet
2013-04-11 16:02             ` Willy Tarreau [this message]
2013-04-11 16:02               ` Willy Tarreau
2013-04-11 16:02               ` Willy Tarreau
2013-04-11 16:02               ` Willy Tarreau
2013-04-11 16:10               ` Eric Dumazet
2013-04-11 16:10                 ` Eric Dumazet
2013-04-11 16:10                 ` Eric Dumazet
2013-04-11 16:59           ` Sebastian Hesselbarth
2013-04-11 16:59             ` Sebastian Hesselbarth
2013-04-11 16:59             ` Sebastian Hesselbarth
2013-04-11 17:13             ` Willy Tarreau
2013-04-11 17:13               ` Willy Tarreau
2013-04-11 17:13               ` Willy Tarreau
2013-04-11 17:31         ` David Miller
2013-04-11 17:31           ` David Miller
2013-04-11 17:31           ` David Miller
2013-04-11 17:35           ` Eric Dumazet
2013-04-11 17:35             ` Eric Dumazet
2013-04-11 17:35             ` Eric Dumazet
2013-04-11 17:51           ` Willy Tarreau
2013-04-11 17:51             ` Willy Tarreau
2013-04-11 17:51             ` Willy Tarreau
2013-04-11 17:51             ` Willy Tarreau
2013-04-11 17:59             ` Eric Dumazet
2013-04-11 17:59               ` Eric Dumazet
2013-04-11 17:59               ` Eric Dumazet
2013-04-11 18:02               ` Willy Tarreau
2013-04-11 18:02                 ` Willy Tarreau
2013-04-11 18:02                 ` Willy Tarreau
2013-04-11 18:02                 ` Willy Tarreau
2013-04-11 15:54 ` Eric Dumazet
2013-04-11 15:54   ` Eric Dumazet
2013-04-11 15:54   ` Eric Dumazet
2013-04-11 17:55 ` Ben Hutchings
2013-04-11 17:55   ` Ben Hutchings
2013-04-11 17:55   ` Ben Hutchings
2013-04-11 18:07   ` Sebastian Hesselbarth
2013-04-11 18:07     ` Sebastian Hesselbarth
2013-04-11 18:07     ` Sebastian Hesselbarth
2013-04-11 18:07     ` Sebastian Hesselbarth
2013-04-11 20:22 ` David Miller
2013-04-11 20:22   ` David Miller
2013-04-11 20:22   ` 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=20130411160258.GI1910@1wt.eu \
    --to=w@1wt.eu \
    --cc=andrew@lunn.ch \
    --cc=buytenh@wantstofly.org \
    --cc=dale@farnsworth.org \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=florian@openwrt.org \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=netdev@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=smoch@web.de \
    /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.