Date: Fri, 05 Sep 2014 23:44:43 +0200 From: Hans Petter Selasky <hps@selasky.org> To: Eric Joyner <ricera10@gmail.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, Scott Long <scottl@freebsd.org>, Jack F Vogel <jfvogel@gmail.com> Subject: Re: [RFC] Patch to improve TSO limitation formula in general Message-ID: <540A2ECB.8010502@selasky.org> In-Reply-To: <CA%2Bb0zg9MbRFYbJL6hZ4-j6ChQ=LPSfCkLRcDvUSnUH%2Bug%2BY-zA@mail.gmail.com> References: <540A0301.9040701@selasky.org> <CA%2Bb0zg9MbRFYbJL6hZ4-j6ChQ=LPSfCkLRcDvUSnUH%2Bug%2BY-zA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?540A2ECB.8010502>