Date: Mon, 08 Sep 2014 07:53:16 +0200 From: Hans Petter Selasky <hps@selasky.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-net@freebsd.org, Eric Joyner <ricera10@gmail.com>, 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: <540D444C.6090904@selasky.org> In-Reply-To: <1762951742.33012989.1409954952800.JavaMail.root@uoguelph.ca> References: <1762951742.33012989.1409954952800.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09/06/14 00:09, Rick Macklem wrote: > Hans Petter Selesky wrote: >> 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. >> > Well, I'm no architecture expert, but I really doubt the CPU delay of a > non-power of 2 multiply/divide is significant related to doing smaller > TSO segments. Long ago (as in 1970s) I did work on machines where shifts > for power of 2 multiply/divide was preferable, but these days I doubt it > is going to matter?? > >>> - 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. Hi, Maybe that can be a separate parameter? I see that your patch assumes that a segment can be any-length. That is not always the case. Remember there are JUMBO mbufs too. With my patch, the maximum segment size is a separate parameter. The total number of TSO bytes is then not so useful. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?540D444C.6090904>