Date: Sun, 6 Jan 2008 18:37:19 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: arch@FreeBSD.org, kmacy@FreeBSD.org, net@FreeBSD.org Subject: Re: Network device driver KPI/ABI and TOE Message-ID: <20080106182340.K105@fledge.watson.org> In-Reply-To: <47811904.4060300@elischer.org> References: <20080106124517.G105@fledge.watson.org> <47811904.4060300@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 6 Jan 2008, Julian Elischer 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.. Disruptive mbuf packet header layout changes during the lifetime of a -STABLE branch are already precluded by the ABI/KPI policy, since knowledge of the packet header layout is compiled into all network device drivers. What I'm more concerned about is the new exposure of internal data structures and algorithms, and a resulting freeze of those data structures and algorithms if we were to apply our current ABI/PI policy to the TOE interfaces. I don't think we should apply it there for the forseeable future, and we should make sure there's no confusion for device vendors or end-users who may have come to rely on the stability of ifnet and related interfaces and hence assume it also applies to the new TOE interfaces. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080106182340.K105>