Network device driver KPI/ABI and TOE

[Julian Elischer]

Robert Watson wrote:
> 

> There's also the opportunity to think about whether it's possible to 
> harden things in such a ways as to not give up our flexibility to keep 
> maintaining and improving TCP (and other related subsystems), yet 
> improving the quality of life for a third party TOE driver maintainer.  
> For example, might we provide accessor routines for certain data 
> structures, or attempt to structure things to hide more of TCP locking 
> from a TOE implementation?  Should we suggest that non-native TOE 
> implementations rely less on our TCP code and provide there own where 
> the hardware doesn't provide a complete implementation, in order to 
> avoid building dependency on things that we know will change?

I think the answer is to do as you suggest, and provide some sort of 
interface with access methods so that TOE doesn't see so much of the 
internal side of the networking, but has methods (no matter how 
specialised) to do these things.

Unfortunately I am not sure that can be done in all situations..
for example I'm not sure you could isolate a change in the mbuf
packet header. (That is a whole different discussion.. I think
we may need to give mbufs a workover for the 21st century but I
digress...)

I'll read this again when I have more time.. I'm of course
"interested" due to various bits of work I have going..


> 
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"