> > I agree that this fixes an incorrect logic, but its incomplete as the
> > bnx2x 'bp->flags' no longer represent the correct logic. I.e., it
> > might cause additional issues down the road, as the 'fp->mode' and 'fp-
> >disable_tpa'
> > are no longer in sync.
>
> > We already have a fix for thi
On 04/27/2015 08:15 PM, Yuval Mintz wrote:
> I agree that this fixes an incorrect logic, but its incomplete as the bnx2x
> 'bp->flags' no longer represent the correct logic. I.e., it might cause
> additional issues down the road, as the 'fp->mode' and 'fp->disable_tpa'
> are no longer in sync.
> W
From: Yuval Mintz
Date: Mon, 27 Apr 2015 18:15:44 +
>>> bnx2x's 'disable_tpa=1' module option is not respected properly and TPA
>>> (transparent packet aggregation) remains enabled. Even though the
>>> module option causes LRO to be disabled, TPA is enabled in GRO mode.
>>>
>>> Additionally,
>> bnx2x's 'disable_tpa=1' module option is not respected properly and TPA
>> (transparent packet aggregation) remains enabled. Even though the
>> module option causes LRO to be disabled, TPA is enabled in GRO mode.
>>
>> Additionally, disabling GRO via ethtool then has no effect. One can
>> still
From: Michal Schmidt
Date: Mon, 27 Apr 2015 17:20:38 +0200
> bnx2x's 'disable_tpa=1' module option is not respected properly and TPA
> (transparent packet aggregation) remains enabled. Even though the
> module option causes LRO to be disabled, TPA is enabled in GRO mode.
>
> Additionally, disabl
