Re: TSO / LSO
Re: TSO / LSO
- Subject: Re: TSO / LSO
- From: Andrew Gallatin <email@hidden>
- Date: Wed, 3 Jan 2007 09:44:22 -0500 (EST)
<...>
Terry Lambert writes:
> On Jan 2, 2007, at 10:39 AM, Andrew Gallatin wrote:
> > Josh Graessley writes:
> >>
> >> No. TCP offload support is something on the to-do list. It's just a
> >> question of resources and priorities. As much of a mess as that will
> >> create, there is potentially a huge upside. The question is, how many
> >> people will benefit from it whether there are more pressing issues.
> >
> > Full TCP offload (like Micrsoft's Chimney) is a much bigger, and
> > nastier can of worms than TSO (aka LSO), and could certainly be
> > described as a "mess to create."
>
> Everything old is new again... I remember "full TCP offload" in
> Ungerman-Bass cards in 286's for Xenix, and in DEQNA cards on Microvax
> II hardware, back in the late 1980's... 8-).
>
I agree with you there :)
<...>
> Actually, the amount of FreeBSD changes for this is a somewhat
> disingenuous representation of the amount of actual change to MacOS X
> necessary to support TSO.
<...>
> Personally, I'd ball-park it at around 6 weeks, if we include all the
<...>
You obviously know the Darwin TCP/IP stack better than I, so I cannot
argue with your estimate up to this point. However, the statements
below make me think you are over-estimating the complexity of TSO:
> No one is arguing that it isn't a win, particularly for specific
> hardware; however, until relatively recently, the vast majority of
> GigE chipsets have, for the most part, had very small amounts of
> buffer space, compared to that necessary for dealing with a useful
> window for a high latency link, or even for the 9K "jumbograms". This
<...>
> For TSO, the issue is bigger than the jumbogram issue, since the chip
> has to support fragging - a virtual MTU smaller than the MTU it
> advertises to the OS, and the OS has to support communicating the path
> MTU discovery information back to the card so that it knows where to
> frag, and deep transmit (and receive, if it's done right) queues, and
> so on.
There are 3 problems with the above:
1) The NIC does not advertise any sort of MTU. The stack just sends
down the biggest frame it can (ip_len is 16 bits, so the max is 64K-1
for IPv4..). The NIC is responsible for splitting this into as many
packets as required.
2) The NIC is implicitly informed of the path MTU by the TCP stack
tagging the frame with the TCP MSS (m->m_pkthdr.tso_segsize in FreeBSD
terms). The packets a NIC generates are limited to the MSS + the size
of the template TCP/IP + link-layer headers.
3) There is no need to buffer up an entire window on the NIC. All you
really need to buffer on the NIC is one frame's worth of data (so that
you can properly send the frame on the wire).
Drew
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden