Subject: Re: CVS commit: src/sys/netinet
To: Matt Thomas <matt@3am-software.com>
From: Jonathan Stone <jonathan@dsg.stanford.edu>
List: tech-net
Date: 03/11/2005 11:35:51
In message <eaf8faa38a9de7a8a8fe443141444a37@3am-software.com>,
Matt Thomas writes:
>After pondering this for awhile, I think the solution is even easier.
>If you can't fit it into your descriptors, split it up. That's what
>the hardware would do.
>
>copy the ip & hdrs to a new header mbuf, tweak tcp_seq & ip_len
>appropriately (maybe ip_id [what do the adapters do for ip_id?] too).
I think its harder than that: the two space domains (sosend bufs, vs.
packing into Tx descriptors, with hardware-dependent constraints on
length, aligment, etc.) are incommensurate. Only the driver can realy
tell for sure a given mbuf chain can be sent via large-send.
Also if (dim, unpleasant) memory serves, the way new bge devices
(5705, and later PCI-e "server" nics?) support large-send is atrocious.
The chip requires the driver to put a descriptor for the entire
``large send' into on-chip registers. As far as I could see, bge chips
can only support one outstanding large-send transaction: if you want
to send more, you have to wait for the current large-send to complete,
then field an interrupt. Thus, to avoid reordering large-send TCP
output with normal non-large send TCP output (TCP reordering being a
Bad Thing), you basically have to stall the entire Tx queue.
(I dunno about the 5706, though).
I dont recall if the 8169 has a similar gotcha.