At 11:35 AM 3/11/2005, Jonathan Stone wrote:

>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.

If the driver can't large send it, it must perform enough segmentation
so that it can be sent.  If that mean until it's in individual segments,
so be it (it can detect that and turn off TSO).

>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).

"A descriptor"?  No s/g?  You don't have to stall the entire TX queue,
just TCP traffic (and probably only that traffic that would advance the
sequence number). :)


-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.