Re: RFC: TSO patch for current

On 9/4/06, Andre Oppermann <andre_at_freebsd.org> wrote:
> 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.

This looks cool Andre, I've been in vacation mode the past couple days,
but when I get to work tomorrow I'll look at it more closely and give it a
try with my driver changes.

Thanks :)

Jack