Hi, Rick,
Does these patches will commit to the stable soon, or I had to patch it manually?

Regards
Simon

于 14-3-28 6:44, Rick Macklem 写道:
Christopher Forgeron wrote:






On Wed, Mar 26, 2014 at 9:35 PM, Rick Macklem < rmack...@uoguelph.ca
wrote:




I've suggested in the other thread what you suggested in a recent
post...ie. to change the default, at least until the propagation
of driver set values is resolved.

rick



I wonder if we need to worry about propagating values up from the
sub-if's - Setting the default in if.c means this is set for all
if's, and it's a simple 1 line code change. If a specific 'if' needs
a different value, it can be set before ether_attach() is called.


I'm more concerned with the equation we use to calculate if_hw_tsomax
- Are we considering the right variables? Are we thinking on the
wrong OSI layer for headers?

Well, I'm pragmatic (which means I mostly care about some fix that works),
but it seems to me that:
- The problem is that some TSO enabled network drivers/hardware can only
   handle 32 transmit segments (or 32 mbufs in the chain for the TSO packet
   to be transmitted, if that is clearer).
--> Since the problem is in certain drivers, it seems that those drivers
     should be where the long term fix goes.
--> Since some hardware can't handle more than 32, it seems that the
     driver should be able to specify that limit, which tcp_output() can
     then apply.

I have an untested patch that does this by adding if_hw_tsomaxseg.
(The attachment called tsomaxseg.patch.)

Changing if_hw_tsomax or its default value is just a hack that gets tcp_output()
to apply a limit that the driver can then fix to 32 mbufs in the chain via
m_defrag().

Since if_hw_tsomax (and if_hw_tsomaxseg in the untested patch) aren't
propagated up through lagg, that needs to be fixed.
(Yet another attached untested patch called lagg.patch.)

As I said before, I don't see these patches getting tested/reviewed etc
in time for 9.3, so I think reducing the default value of if_hw_tsomax
is a reasonable short term hack to work around the problem.
(And it sounds like Pyun YongHyeon has volunteered to fix many of the
drivers, where the 32 limit isn't a hardware one.)

rick



_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Reply via email to