[Prism54-devel] Fragments for transmit; copy skbuf on receive?

[Aurelien]

Hi,

On Tue, 30 Dec 2003 23:20:49 +0100
Jens Maurer <Jens.Maurer@gmx.net> wrote:

> I believe we should get rid of transmit fragment handling.
> Our MTU setting of 1500 (as with any ethernet device) will ensure
> that we're not called with oversized packets. That would
> reduce the complexity of the transmit code path.

That seems true. But I'm wondering why guys from intersil wrote it with multiple fragment handling... Maybe to show that their device can send frames bigger than 1536 ?

> In our receive path, the upper layers get the skbuf that was filled
> by the device DMA. This requires tearing down the DMA mapping
> of this skbuf (pci_unmap_single), allocating a new skbuf and
> re-establishing a DMA mapping for that (pci_map_single).
> Other network device drivers employ a parameter "rx_copybreak" that
> decides whether the packet is small enough to allocate a new
> skbuf, copy the data there, and re-use the original skbuf for the
> next packet.  (You need use pci_dma_sync_single to make sure the
> CPU sees all device DMA updates.)  The idea is that on some
> platforms, tearing down and creating a DMA mapping is an expensive
> (i.e. slow) endeavor.
> 
> The rx_copybreak setting is different for each device driver,
> values such as 100 or 200 bytes are common.  The tulip driver
> differentiates the platforms: On x86, frames < 100 bytes are
> copied, on other platforms such as SPARC, ARM, or MIPS, we
> memcpy ALL packets (the limit is 1518 bytes).

I have no idea of what the gain could be. But it sounds like a clever behavior.

If you look at the TODO, you'll see :
 * midpri: rethink current queue handling, it looks quite hacky/ulgy right now

I don't know who added this line (maybe hvr ?), but if you want, you can do some work there...

...And justice for all