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

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_at_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_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"
> >
>