RFC: TSO patch for current

[Jack Vogel]

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.

What were you thinking of doing?

Cheers,

Jack