Re: RFC: TSO patch for current

Robert Watson wrote:
> On Fri, 1 Sep 2006, Jack Vogel wrote:
> 
>> This is a patch for the stack and the em driver to enable TSO on 
>> CURRENT. Previously I had problems getting it to work, but this is 
>> functional.
>>
>> I should note that CURRENT is being a pain right now, when I comment 
>> out em in the config the kernel panics coming up, so I had to 
>> substitute this code into the tree. Rather bizarre :)
>>
>> I have this functionality running on a 6.1 based system, and our test 
>> group is already testing against that driver, so far things are 
>> looking good.
>>
>> I have designed it so the driver can continue to be built without 
>> support. There is also a sysctl in the stack code so you can set 
>> net.inet.tcp.tso_enable on or off and compare.
>>
>> I know there may be some refinements to add in, but I would like to 
>> get this into CURRENT as a start.
> 
> 
> Per my earlier comments, I would like to see the issue of doing an 
> on-demand segmentation of TCP at the IP layer in the event that the 
> early route decision becomes stale (i.e., ipfw fwd, ipsec, etc), as 
> occurs in the NetBSD code. Likewise, I think Andre's comment about 
> making the routing decision up front for the TCP connection as part of 
> the existing search for PMTU information makes sense.  I'm more 
> interested in seeing the former addressed than the latter before the 
> commit, though, which can quite easily follow.

In the patch I posted yesterday into this thread the TSO decision is
done at connection setup time in tcp_mss() where all other initial TCP
connection parameters are initilized as well.  If the same interface
we took the MTU values from, is found to support TSO it gets enabled for
this connection too.  Should the egress interface change during the
lifetime of the connection and the new one doesn't support TSO we get
an EMSGSIZE error from ip_output(), disable TSO for this connection and
have tcp_output() resend the data again while doing the segmentation
itself as usual.  Should the connection change back to the TSO capable
interface later on we don't re-enable TSO for the connection though.
OTOH having a bulk transfer TCP session (where TSO actually helps) migrate
between interface is a *very* rare occurence and not worth special casing
for it.

-- 
Andre