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

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_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscribe_at_freebsd.org"
>