TSO

[Rick Macklem]

Jack Vogel wrote:
> Nah that wouldn't be very practical would it :) I was thinking the
> max
> segment value could be
> kept in the interface struct, but as I think about it I guess that
> wouldn't
> really help. So, you
> have other ideas Scott??
> 
> Jack
> 
I won't pretend to be Scott, but I have an untested patch that allows
the device to specify its maximum # of segments for transmit (something
like if_hw_maxtsoseg to go along with if_hw_maxtso) and then
tcp_output() uses that along with if_hw_maxtso to limit the segment
size handed to the device. (I don't have any hardware that does TSO,
so I can't do anything more with it. If anyone wants to look at it,
email and I'll send you a copy.)

John-Mark Gurney looked at it and mentioned a concern w.r.t. "fixing
the drivers that could handle long mbuf chains". I think this means
that the default would need to be large instead of 30.

rick

> 
> 
> On Wed, Feb 26, 2014 at 1:13 PM, Scott Long <scott4long at yahoo.com>
> wrote:
> 
> > Are you proposing that the network stack track the physical memory
> > segment
> > details of the mbufs as they are formed and chained together?
> >
> > Scott
> >
> > On Feb 26, 2014, at 10:27 AM, Jack Vogel <jfvogel at gmail.com> wrote:
> >
> > > Drivers have to work with whatever the requirements/limitations
> > > of the
> > > hardware,
> > > if you have a 5 lb sack you shouldn't be surprised if some drops
> > > when you
> > > shove
> > > 6 lbs at it :)
> > >
> > > Why not have this limit in the interface so the stack can avoid
> > > exceeding
> > > it?
> > >
> > > Jack
> > >
> > >
> > >
> > >
> > > On Wed, Feb 26, 2014 at 10:07 AM, John-Mark Gurney
> > > <jmg at funkthat.com>
> > wrote:
> > >
> > >> Sami Halabi wrote this message on Wed, Feb 26, 2014 at 19:37
> > >> +0200:
> > >>> I'm reading (almost) all mailing emails in mailig list...
> > >>>
> > >>> Almost every / many problem in network performancr / packets
> > >>> loss ended
> > >> up
> > >>> suggesting disabling TSO.
> > >>>
> > >>> I wonder why.. Is it a bug in the implementation? Or bybdesign?
> > >>> What are the usecases that TSO is needed? Myabe  it should be
> > >>> disabled
> > bt
> > >>> default?
> > >>
> > >> It looks like most of the problems are in drivers that don't
> > >> handle
> > >> packets with a large number of segments properly...  The problem
> > >> is
> > >> that some drivers limit to how segments a packet can be broken
> > >> into, and
> > >> then if they receive such a packet, instead of doing their
> > >> darnest to
> > >> deliver it, they drop it...
> > >>
> > >> There are some patches that help address the issue...
> > >>
> > >> Drivers should complain more loudly when a packet gets dropped
> > >> by the
> > >> driver, since it is likely that the OS may retry the same
> > >> packet,
> > >> just to have it fail, though sometimes it'll try a different
> > >> set, and
> > >> it might go through, so all the user may notice is a slight lag
> > >> if
> > >> they notice anything at all...
> > >>
> > >> --
> > >>  John-Mark Gurney                              Voice: +1 415 225
> > >>  5579
> > >>
> > >>     "All that I will do, has been done, All that I have, has
> > >>     not."
> > >> _______________________________________________
> > >> freebsd-net at freebsd.org mailing list
> > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > >> To unsubscribe, send any mail to
> > >> "freebsd-net-unsubscribe at freebsd.org"
> > >>
> > > _______________________________________________
> > > freebsd-net at freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > > To unsubscribe, send any mail to
> > > "freebsd-net-unsubscribe at freebsd.org"
> >
> >
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to
> "freebsd-net-unsubscribe at freebsd.org"
>