[Intel-wired-lan] [next PATCH S48 3/7] i40e: Drop redundant Rx descriptor processing code
Bowers, AndrewX
andrewx.bowers at intel.com
Wed Sep 28 18:50:10 UTC 2016
> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On
> Behalf Of Bimmy Pujari
> Sent: Tuesday, September 27, 2016 11:29 AM
> To: intel-wired-lan at lists.osuosl.org
> Subject: [Intel-wired-lan] [next PATCH S48 3/7] i40e: Drop redundant Rx
> descriptor processing code
>
> From: Alexander Duyck <alexander.h.duyck at intel.com>
>
> This patch cleans up several pieces of redundant code in the Rx clean-up
> paths.
>
> The first bit is that hdr_addr and the status_err_len portions of the Rx
> descriptor represent the same value. As such there is no point in setting
> them to 0 before setting them to 0. I'm dropping the second spot where we
> are updating the value to 0 so that we only have 1 write for this value instead
> of 2.
>
> The second piece is the checking for the DD bit in the packet. We only need
> to check for a non-zero value for the status_err_len because if the device is
> done with the descriptor it will have written something back and the DD is
> just one piece of it. In addition I have moved the reading of the Rx descriptor
> bits related to rx_ptype down so that they are actually below the dma_rmb()
> call so that we are guaranteed that we don't have any funky 64b on 32b calls
> causing any ordering issues.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck at intel.com>
> Change-ID: I256e44a025d3c64a7224aaaec37c852bfcb1871b
> ---
> Testing Hints:
> We should still receive packets normally. This change could impact
> the Rx hashing, but I don't know of any tests for skb->hash. The
> only possibility I can think of would be to add a trace point.
>
> drivers/net/ethernet/intel/i40e/i40e_txrx.c | 18 ++++++------------
> drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 18 ++++++------------
> 2 files changed, 12 insertions(+), 24 deletions(-)
Tested-by: Andrew Bowers <andrewx.bowers at intel.com>
Packet receive functions work as expected
More information about the Intel-wired-lan
mailing list