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.
We
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 this issue, we
From: Yuval Mintz yuval.mi...@qlogic.com
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.
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 observe tpa_*
From: Michal Schmidt mschm...@redhat.com
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.
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 observe
