Mark Johnson wrote:
Why not put it in the DDI? There's nothing GLD specific about DMA.
Who else would use it besides NICs?
Who knows? I just don't see any point in trying to be restrictive
though. STREAMS blocks and associated functions are part of the DDI so
why not provide DMA mapping functions specific to them in the DDI?
The diversity of NIC h/s is the reason why the goal of common codepath
optimization is probably not realistic. I've come across many NIC
drivers and the schemes for driving different chips is usually too
diverse; it would be possible to make code common but it would just be
equally bad on all chips.
I certainly can see difficulties on the rx side. It would
be interesting to hear about a case which was a one off one
though.. I would imagine you would be able to bin most of
them.
My driver has relatively complex receive path because I do LRO in s/w.
Thus I have to maintain flow tables and coalescing state; I agree that
this code looks like a candidate for making common but my h/w generates
a hash which can be used to optimize flow lookup; can that be made
common? Also, code placement causing i-cache misses turned out to be
significant and I even went to the trouble of using some pretty
cumbersom macros to try to tune out function call overhead; can that be
made common?
I'd be interested in examples on the TX side where this
is the case.
Commonality on the TX side could be defeated by fragmentation rules.
Soft LSO would seem like a a good thing to make common but can you do it
in such a way that can handle h/w with a restriction that fragments not
aligned on a 16 byte boundary cannot exceed 512 bytes in length? (Yes,
the h/w is broken but show me a piece of h/w that is not). A driver
writer's job is to cover up mistakes in h/w design :-)
Paul
--
===================================
Paul Durrant
http://www.linkedin.com/in/pdurrant
===================================
_______________________________________________
networking-discuss mailing list
[email protected]
