Date: Mon, 8 Sep 2014 16:32:31 -0700 From: Eric Joyner <ricera10@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: Hans Petter Selasky <hps@selasky.org>, "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: <CA%2Bb0zg_JuNPu8wEUb6wSwJdQ=bW7rHwMWza_-_dr5aSD2jQ=9A@mail.gmail.com> In-Reply-To: <1882852102.33387181.1410177939640.JavaMail.root@uoguelph.ca> References: <540D444C.6090904@selasky.org> <1882852102.33387181.1410177939640.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Let me remove my concerns earlier in the thread -- this patch won't negatively affect any of our drivers; and the problem I mentioned with ixl would require a change somewhere further up the stack. --- - Eric Joyner On Mon, Sep 8, 2014 at 5:05 AM, Rick Macklem <rmacklem@uoguelph.ca> wrote: > Hans Petter Selasky wrote: > > 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. > > > I thought JUMBO mbufs were only going to be used on the receive side, > however I suppose if a packet is received into a JUMBO mbuf and then > forwarded on another interface... > > > With my patch, the maximum segment size is a separate parameter. The > > total number of TSO bytes is then not so useful. > > > Well, if you are referring to if_hw_tsomax, I'm not sure it was the > best plan to begin with. It was implemented for xen and I'm not sure > that any other driver uses it as of now. > > However... > I'm not a network/hardware guy, but it seems some devices do have > the IP_MAXPACKET limit (use the ip_len field in the ip header to > know how large the TSO segment is). There is also at least one device > (82598 chip for "ix" driver) that can handle more that IP_MAXPACKET, > so it seems appropriate to have a value that the driver can set. > > Since the maximum size of the gather list for transmit does seem to > vary a lot between devices, with several handling less than 35, it > does seem appropriate to allow drivers to specify that. > > If devices can't handle a single gather entry over a certain size, > I think that does need to be specified along with the max size of > the gather list, since the driver will need to use multiple gather > entries for a single mbuf and tcp_output() should take that into > account. > > In summary, yep, I basically agree. > > rick > ps: Who will look at your patch soon. > > > --HPS > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org" > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2Bb0zg_JuNPu8wEUb6wSwJdQ=bW7rHwMWza_-_dr5aSD2jQ=9A>