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! --HPSReceived 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