Re: RFC: TSO patch for current

Jack Vogel wrote:
> On 9/2/06, Andre Oppermann <andre_at_freebsd.org> wrote:
>> 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.
>>
>> I can't comment on the em part but the tcp_output.c stuff looks
>> very much like a straight port from NetBSD.  If we take code from
>> the other BSDs we have to remark this in the emails we send with
>> patches and the commit message (otherwise we get accused of 'stealing
>> without attribution').  Although the code would work I have some ideas
>> to implement this in a different way for our stack (we have certain
>> divergence from the other BSDs).  If you don't get an alternative
>> patch form me until this Thursday be free to go with this patch taking
>> into consideration Robert's comments and mine from your earlier version.
> 
> Yes, I was planning on adding the code Robert talked about, it doesnt
> change anything fundamental in this patch.
> 
> What I would like to see in some ways is an idea from what Linux does,
> but it would change the stack more than this does. We would remove
> all code that segments from tcp and do it just before calling the driver,
> in effect the routine Robert is talking about would be the normal path,
> doing software segmentation, and at that same point we would discover
> that the interface was TSO capable and call that.  I think at that point
> we would have easy access to the ifp struct and it would eliminate the
> need for the discovery routine in tcp_subr.c.

I'm not sure this is necessarily the way to go.  We don't want to marry
the higher layer code too closely to the lower layers.

> What were you thinking of doing?

Please check out my TSO patch here:

  http://people.freebsd.org/~andre/tso-20060903.diff

It compiles but I haven't tested it live traffic yet.  My approach is
quite different from the NetBSD one your patch is based on.  IMO the
NetBSD approach is not entirely correct given the actual code flow in
tcp_output.

-- 
Andre