Re: [PATCH] Super TSO

["David S. Miller" <davem@davemloft.net>]

From: "Leonid Grossman" <leonid.grossman@neterion.com>
Date: Thu, 19 May 2005 17:36:25 -0700

> > > One likely scenario where this feature is desirable is a 
> > system with 
> > > highly fragmented memory.
> > > In this case, the number of physical fragments per TSO 
> > frame could be 
> > > always so high that it will be cheaper (on a given 
> > platform) to copy 
> > > the frame than to DMA it.
> > 
> > We always chop up the user data into individual system pages 
> > when we build TSO frames, so I can't see how any kind of 
> > memory fragmentation could be an issue.
> 
> This is exactly what I wanted to hear :-)
> If the TSO implementation guarantees that the payload comes (for the most
> part) 
> in physically continuous pages, then the number of fragments 
> will never get out of whack, and my argument indeed becomes invalid.

You misunderstand me.  The TCP segmenter splits the incoming
user data into page size'd chunks.  So a 64K packet uses
64K / PAGE_SIZE individual pages.

The only thing the driver author needs to be aware of wrt. this
is to never wake up the TX netif queue until at least
"MAX_SKB_FRAGS + 1" transmit descriptors are available.

You'll see that every driver setting NETIF_F_SG implements
this test.

> Sure. On the other hand, the TCP code is unaware of the copy vs. DMA
> costs on a particular NIC (well, this is actually more specific to a
> system than to a NIC).  But I guess as long as both the packet size
> and the number of fragments will not get very big at the same time,
> A NIC will be OK.

They can and will be as large as "MAX_SKB_FRAGS + 1".