On 9/2/06, Andre Oppermann <[EMAIL PROTECTED]> 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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
