Re: [RFC] Patch to improve TSO limitation formula in general

From: Hans Petter Selasky <hps_at_selasky.org>
Date: Fri, 05 Sep 2014 23:44:43 +0200
On 09/05/14 23:19, Eric Joyner wrote:
> There are some concerns if we use this with devices that ixl supports:
>
> - The maximum fragment size is 16KB-1, which isn't a power of 2.
>

Hi Eric,

Multiplying by powers of two are more fast, than non-powers of two. So 
in this case you would have to use 8KB as a maximum.

> - You can't get the maximum TSO size for ixl devices by multiplying the
> maximum number of fragments by the maximum size.
> Instead the number of fragments is AFAIK unlimited, but a segment can only
> span 8 mbufs (including the [up to 3] mbufs containing the header), and the
> maximum TSO size is 256KB.
>
> And one question:
>
> - Is hdr_size_log2 supposed to be the length of the L2 header? We can fit
> 254 L2 bytes in our hardware during a TSO, so if that's the value, I guess
> that's fine, barring the it-not-being-a-power-of-2 issue.

This is the ethernet / vlan headers. It is added with the TCP/IP-header 
in the end.

>
> With all that said, the 8 mbuf limit per segment issue is a TSO limitation
> that we'd like to notify the stack about, so I wonder if that could be
> incorporated along with this. Right now, our driver checks to see if a
> segment in a TSO spans more than six mbufs and then m_defrag()'s the entire
> chain if one exists; it's less than optimal but necessary to prevent errors.

It is not impossible to move from log2 syntax to non-log2 syntax, hence 
the logic will be exactly the same, only that the required division and 
multiplication will have a bit overhead I guess.

Could you make a patch on top of my patch with the changes you think are 
required to fully support the ixl hardware? Or propose a new patch which 
also serves the MLX needs?

Thank you!

--HPS
Received on Fri Sep 05 2014 - 19:44:50 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:51 UTC