On ThunderX 88xx pass 2.x chips when TSO is offloaded to HW,
HW posts a CQE for every TSO segment transmitted. Current code
does handles this, but is prone to issues when segment sizes are
small resulting in SW processing too many CQEs and also at times
frees a SKB which is not yet transmitted.
This patch handles the errata in a different way and eliminates issues
with earlier approach, TSO packet is submitted to HW with post_cqe=0,
so that no CQE is posted upon completion of transmission of TSO packet
but a additional HDR + IMMEDIATE descriptors are added to SQ due to
which a CQE is posted and will have required info to be used while
cleanup in napi. This way only one CQE is posted for a TSO packet.
Signed-off-by: Sunil Goutham <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 7ceb8a1319ec64954459d474dd4a8c3c60ff0999)
Signed-off-by: dann frazier <email address hidden>
71f6b37...
by
Sunil Goutham <email address hidden>
net: thunderx: Fix for HW issue while padding TSO packet
There is a issue in HW where-in while sending GSO sized pkts
as part of TSO, if pkt len falls below configured min packet
size i.e 60, NIC will zero PAD packet and also updates IP total length.
Hence set this value to lessthan min pkt size of MAC + IP + TCP
headers, BGX will anyway do the padding to transmit 64 byte pkt
including FCS.
Signed-off-by: Sunil Goutham <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 57e81d44b0e1aa4dcb479ff8de8fc34cf635d0e8)
Signed-off-by: dann frazier <email address hidden>
When I fixed the dp rate selection in:
092c96a8ab9d1bd60ada2ed385cc364ce084180e
drm/radeon: fix dp link rate selection (v2)
I accidently dropped the special handling for NUTMEG
DP bridge chips. They require a fixed link rate.
Reviewed-by: Christian König <email address hidden>
Reviewed-by: Ken Wang <email address hidden>
Reviewed-by: Harry Wentland <email address hidden>
Tested-by: Ken Moffat <email address hidden>
Signed-off-by: Alex Deucher <email address hidden>
Cc: <email address hidden>
(cherry picked from commit c8213a638f65bf487c10593c216525952cca3690)
Signed-off-by: Tim Gardner <email address hidden>
This change makes it so that we can just use function pointers instead of
having to identify if a given VF is running on a Linux or Windows PF. By
doing this we can avoid having to pull too much information out of the
lower layers and can instead just make use of the mac_ops pointers since
they should differ between the two types of VFs anyway.
Signed-off-by: Alexander Duyck <email address hidden>
Tested-by: Andrew Bowers <email address hidden>
Signed-off-by: Jeff Kirsher <email address hidden>
(cherry picked from commit 2f8214fe6811a246265629d81af2313695c63f4d)
Signed-off-by: Tim Gardner <email address hidden>
Acked-by: Brad Figg <email address hidden>
Acked-by: Kamal Mostafa <email address hidden>
We noticed performance issues with VF interface on sparc compared
to PF. Setting the RX to IXGBE_DCA_RXCTRL_DATA_WRO_EN brings it
on far with PF. Also this matches to the default sparc setting in
PF driver.
Signed-off-by: Babu Moger <email address hidden>
Acked-by: Sowmini Varadhan <email address hidden>
Tested-by: Andrew Bowers <email address hidden>
Signed-off-by: Jeff Kirsher <email address hidden>
(cherry picked from commit 33b0eb15961393d8c60e7c4bddd23da53cd1c2e4)
Signed-off-by: Tim Gardner <email address hidden>
Acked-by: Brad Figg <email address hidden>
Acked-by: Kamal Mostafa <email address hidden>
On Hyper-V, the VF/PF communication is a via software mediated path
as opposed to the hardware mailbox. Make the necessary
adjustments to support Hyper-V.
Signed-off-by: K. Y. Srinivasan <email address hidden>
Tested-by: Andrew Bowers <email address hidden>
Signed-off-by: Jeff Kirsher <email address hidden>
(cherry picked from commit c6d45171d706c2b5efa3d5ee7a8260c14b6367c0)
Signed-off-by: Tim Gardner <email address hidden>
Acked-by: Brad Figg <email address hidden>
Acked-by: Kamal Mostafa <email address hidden>
This patch moves API negotiation into mac_ops. The general idea here is
that with HyperV on the way we need to make certain that anything that will
have different versions between HyperV and a standard VF needs to be
abstracted enough so that we can have a separate function between the two
so we can avoid changes in one breaking something in the other.
Signed-off-by: Alexander Duyck <email address hidden>
Tested-by: Andrew Bowers <email address hidden>
Signed-off-by: Jeff Kirsher <email address hidden>
(cherry picked from commit 7921f4dc4c36e736d7a5b45dfa7b6a755a4fc012)
Signed-off-by: Tim Gardner <email address hidden>
Acked-by: Brad Figg <email address hidden>
Acked-by: Kamal Mostafa <email address hidden>
Also cleanup a case where we're bit shifting a value into place, and use
an unsigned constant. Make use of the unsigned postfix in places where
BIT() macro is not appropriate.
Signed-off-by: Jacob Keller <email address hidden>
Tested-by: Andrew Bowers <email address hidden>
Signed-off-by: Jeff Kirsher <email address hidden>
(cherry picked from commit 8d055cc0c8be92cd6a77193460117f0ab0a05286)
Signed-off-by: Tim Gardner <email address hidden>
Acked-by: Brad Figg <email address hidden>
Acked-by: Kamal Mostafa <email address hidden>
