Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

From: Rick Jones Date: Wed, 22 Jun 2016 14:52:34 -0700 > To get that disabled, one must also get the bnx2x module loaded with > "disable-tpa=1" so the Linux stack GRO gets used instead. And people wonder why I'm difficult about module parameters in drivers

RE: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

> Fundamentally I believe that robust, responsive hardware LRO is not workable > as > the hardware would have to decide to hold onto packets in the hope of merge > candidates arriving soon after. Whereas in the software layer (GRO, > bundling...), the packets are already coming in bursts thanks

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On 24/06/16 17:31, Tom Herbert wrote: > Ed, > Because you took this OT... ;-) > > LRO/GRO is the one of the five common offloads that has no generic > analogue and requires protocol specific logic. For instance each > IP-over-foo encapsulation needs kernel code for GRO, device/driver > code for

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Thu, Jun 23, 2016 at 10:20 PM, Yuval Mintz wrote: >>We already know of one firmware bug you guys have which makes >>it clear that the bnx2x is not doing hardware assisted GRO it is doing >>something else since it performs much worse than GRO if the MSS is >>less than

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Fri, Jun 24, 2016 at 6:09 AM, Edward Cree wrote: > On 23/06/16 18:07, Alexander Duyck wrote: >> I would prefer to see us extend LRO to support "close enough GRO" >> instead of have us extend GRO to also include LRO. > This reminds me of something I've been meaning to

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On 23/06/16 18:07, Alexander Duyck wrote: > I would prefer to see us extend LRO to support "close enough GRO" > instead of have us extend GRO to also include LRO. This reminds me of something I've been meaning to bring up (sorry for slightly OT, but it might turn out relevant after all). In sfc we

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

>We already know of one firmware bug you guys have which makes >it clear that the bnx2x is not doing hardware assisted GRO it is doing >something else since it performs much worse than GRO if the MSS is >less than what it would be based on the MTU. It's a bit nitpicky, isn't it? Claiming this

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Thu, Jun 23, 2016 at 2:06 PM, Yuval Mintz wrote: Then again, if you're basically saying every HW-assisted offload on receive should be done under LRO flag, what would be the use case where a GRO-assisted offload would help? I.e., afaik LRO is

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

>>> Then again, if you're basically saying every HW-assisted offload on >>> receive should be done under LRO flag, what would be the use case >>> where a GRO-assisted offload would help? >>> I.e., afaik LRO is superior to GRO in `brute force' - >>> it creates better packed packets and utilizes

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Wed, Jun 22, 2016 at 9:17 PM, Yuval Mintz wrote: >> Then again, if you're basically saying every HW-assisted offload on >> receive should be done under LRO flag, what would be the use case >> where a GRO-assisted offload would help? > >> I.e., afaik LRO is superior to

RE: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

> > My systems are presently in the midst of an install but I should be > > able to demonstrate it in the morning (US Pacific time, modulo the > > shuttle service of a car repair place) > > stack@np-cp1-comp0002-mgmt:~$ ./netperf -H np-cp1-comp0001-guest -- -G > 1400 -P 12867 -O

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

> Then again, if you're basically saying every HW-assisted offload on > receive should be done under LRO flag, what would be the use case > where a GRO-assisted offload would help? > I.e., afaik LRO is superior to GRO in `brute force' - > it creates better packed packets and utilizes memory

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

>> Claiming that hardware assist GRO is not possible is a plain mantra. > I have no issue claiming hardware assist GRO is possible.  My problem > is saying that the GRO feature flag can be used to enable it.  I would > argue that any packet aggregation at the device or driver level is LRO >

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On 06/22/2016 04:10 PM, Rick Jones wrote: My systems are presently in the midst of an install but I should be able to demonstrate it in the morning (US Pacific time, modulo the shuttle service of a car repair place) The installs finished sooner than I thought. So, receiver:

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Wed, Jun 22, 2016 at 4:52 PM, Rick Jones wrote: > On 06/22/2016 03:56 PM, Alexander Duyck wrote: >> >> On Wed, Jun 22, 2016 at 3:47 PM, Eric Dumazet >> wrote: >>> >>> On Wed, 2016-06-22 at 14:52 -0700, Rick Jones wrote: Had the

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Wed, Jun 22, 2016 at 4:31 PM, Eric Dumazet wrote: > On Wed, 2016-06-22 at 15:56 -0700, Alexander Duyck wrote: > >> It could be that you and Rick are running different firmware. I >> believe you can expose that via "ethtool -i". This is the ugly bit >> about all this.

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Wed, Jun 22, 2016 at 4:31 PM, Eric Dumazet wrote: > On Wed, 2016-06-22 at 15:56 -0700, Alexander Duyck wrote: > >> It could be that you and Rick are running different firmware. I >> believe you can expose that via "ethtool -i". This is the ugly bit >> about all this.

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On 06/22/2016 03:56 PM, Alexander Duyck wrote: On Wed, Jun 22, 2016 at 3:47 PM, Eric Dumazet wrote: On Wed, 2016-06-22 at 14:52 -0700, Rick Jones wrote: Had the bnx2x-driven NICs' firmware not had that rather unfortunate assumption about MSSes I probably would never

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Wed, 2016-06-22 at 14:32 -0700, Alexander Duyck wrote: > The idea behind GRO was to make it so that we had a generic way to > handle this in software. For the most part drivers doing LRO in > software were doing the same thing that the GRO was doing. The only > reason it was

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Wed, 2016-06-22 at 15:56 -0700, Alexander Duyck wrote: > It could be that you and Rick are running different firmware. I > believe you can expose that via "ethtool -i". This is the ugly bit > about all this. We are offloading GRO into the firmware of these > devices with no idea how any of

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On 06/22/2016 03:47 PM, Eric Dumazet wrote: On Wed, 2016-06-22 at 14:52 -0700, Rick Jones wrote: On 06/22/2016 11:22 AM, Yuval Mintz wrote: But seriously, this isn't really anything new but rather a step forward in the direction we've already taken - bnx2x/qede are already performing the same

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Wed, Jun 22, 2016 at 3:47 PM, Eric Dumazet wrote: > On Wed, 2016-06-22 at 14:52 -0700, Rick Jones wrote: >> On 06/22/2016 11:22 AM, Yuval Mintz wrote: >> > But seriously, this isn't really anything new but rather a step forward in >> > the direction we've already taken

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Wed, 2016-06-22 at 14:52 -0700, Rick Jones wrote: > On 06/22/2016 11:22 AM, Yuval Mintz wrote: > > But seriously, this isn't really anything new but rather a step forward in > > the direction we've already taken - bnx2x/qede are already performing > > the same for non-encapsulated TCP. > >

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On 22.06.2016 14:32, Alexander Duyck wrote: > On Wed, Jun 22, 2016 at 11:22 AM, Yuval Mintz wrote: >> This series adds driver support for the processing of tunnel >> [specifically vxlan/geneve/gre tunnels] packets which are >> aggregated [GROed] by the hardware

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On 06/22/2016 11:22 AM, Yuval Mintz wrote: But seriously, this isn't really anything new but rather a step forward in the direction we've already taken - bnx2x/qede are already performing the same for non-encapsulated TCP. Since you mention bnx2x... I would argue that the NIC firmware on

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Wed, Jun 22, 2016 at 11:22 AM, Yuval Mintz wrote: > This series adds driver support for the processing of tunnel > [specifically vxlan/geneve/gre tunnels] packets which are > aggregated [GROed] by the hardware before driver passes > such packets upto the

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

This series adds driver support for the processing of tunnel [specifically vxlan/geneve/gre tunnels] packets which are aggregated [GROed] by the hardware before driver passes such packets upto the stack. >>> First off I am pretty sure this isn't GRO.  This is LRO. >> Nopes.

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Wed, Jun 22, 2016 at 10:16 AM, Yuval Mintz wrote: >>> This series adds driver support for the processing of tunnel >>> [specifically vxlan/geneve/gre tunnels] packets which are >>> aggregated [GROed] by the hardware before driver passes >>> such packets upto the stack.

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

>> This series adds driver support for the processing of tunnel >> [specifically vxlan/geneve/gre tunnels] packets which are >> aggregated [GROed] by the hardware before driver passes >> such packets upto the stack. > First off I am pretty sure this isn't GRO.  This is LRO.  Nopes. This is GRO -

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Wed, Jun 22, 2016 at 1:25 AM, Manish Chopra wrote: > Hi David, > > This series adds driver support for the processing of tunnel > [specifically vxlan/geneve/gre tunnels] packets which are > aggregated [GROed] by the hardware before driver passes > such packets upto

[PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

Hi David, This series adds driver support for the processing of tunnel [specifically vxlan/geneve/gre tunnels] packets which are aggregated [GROed] by the hardware before driver passes such packets upto the stack. Patch 1 - General infrastructure change Exported UDP and GRE gro_complete APIs to