TSO

[Jack Vogel]

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



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