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

[Jens Maurer]

Hello!

Currently, islpci_eth_transmit() has fragment handling, but
islpci_eth_receive() does not have it.

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.

(We need the fragment handling in the management code, because the
firmware may return potentially unbounded lists of APs and such.)

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

Jens Maurer