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
> 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 t
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 LRO
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 what it would be based on t
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 bring up (sorry for
> sligh
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
>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 f
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 superior to GRO in `brute force'
>>> 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 memo
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 GRO in `brute force' -
>>
> > 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 throughput,transpo
> 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 better
>> 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
> regard
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:
root@np-cp1-comp0
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 bnx2x-driven NICs' firmware not had that rather unfortun
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. We are offloading GRO int
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. We are offloading GRO int
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 have noticed.
It could
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 deprecate
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 it
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 f
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 - bnx2x/qede are already
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.
>
> Sinc
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 before driver passes
>>>
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
tho
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 stack.
First off I
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
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.
>
>> First off I am prett
>> 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 - e
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 the stack.
First off I am pr
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
31 matches
Mail list logo