[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160331150438.00005617@unknown>
Date: Thu, 31 Mar 2016 15:04:38 -0700
From: Jesse Brandeburg <jesse.brandeburg@...el.com>
To: Alexander Duyck <aduyck@...antis.com>
Cc: <netdev@...r.kernel.org>, <alexander.duyck@...il.com>,
<intel-wired-lan@...ts.osuosl.org>, <jeffrey.t.kirsher@...el.com>,
<sowmini.varadhan@...cle.com>
Subject: Re: [net PATCH v2] i40e/i40evf: Limit TSO to 7 descriptors for
payload instead of 8 per packet
On Wed, 30 Mar 2016 16:15:37 -0700
Alexander Duyck <aduyck@...antis.com> wrote:
> This patch addresses a bug introduced based on my interpretation of the
> XL710 datasheet. Specifically section 8.4.1 states that "A single transmit
> packet may span up to 8 buffers (up to 8 data descriptors per packet
> including both the header and payload buffers)." It then later goes on to
> say that each segment for a TSO obeys the previous rule, however it then
> refers to TSO header and the segment payload buffers.
>
> I believe the actual limit for fragments with TSO and a skbuff that has
> payload data in the header portion of the buffer is actually only 7
> fragments as the skb->data portion counts as 2 buffers, one for the TSO
> header, and one for a segment payload buffer.
>
> Fixes: 2d37490b82af ("i40e/i40evf: Rewrite logic for 8 descriptor per packet check")
> Signed-off-by: Alexander Duyck <aduyck@...antis.com>
> ---
>
> v2: I realized that I overlooked the check in the inline function and as a
> result we were still allowing for cases where 8 descriptors were being
> used per packet and this would result in 9 DMA buffers. I updated the
> code so that we only allow 8 in the case of a single send, otherwise we
> go into the function that walks the frags to verify each block.
>
> I have tested this using rds-stress and it seems to run traffic without
> throwing any errors.
Looking like it is working for me too with at least the PF.
Acked-by: Jesse Brandeburg <jesse.brandeburg@...el.com>
Should also add:
Reported-by: Sowmini Varadhan <sowmini.varadhan@...cle.com>
Powered by blists - more mailing lists