I took a brief look into this, and yes NIU would benefit a lot from
what the sfc driver is doing and using sw GSO in general.
I think that, in order to work out, the driver has to provide a pool
of DMA buffers to use in some generic fashion.
It seems likely that it's best to give the driver the largest amount
of flexibility wrt. the DMA bits. There are two reasonable ways for
them to implement a header buffer pool:
1) A big coherent DMA block that gets chopped up into fixed size pieces.
2) A free list of kmalloc() buffers that get DMA mapped dynamically
(because such dynamic DMA mappings transfer faster than coherent ones
on some systems).
But anyways, we don't want to be in the business of enforcing one way
or the other in whatever interface we come up with.
So likely what we'll do is have the driver say it can do hw TSO and
then at ->hard_start_xmit() time it calls into the sw GSO engine,
passing header buffers in along the way.
I would start hacking on this beast but I haven't yet come up with
a clean way to share a lot of code with the existing sw GSO engine.
That's the key to implementing this properly.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
