Date: Thu, 10 Jan 2008 17:50:53 -0500 From: gnn@freebsd.org To: Robert Watson <rwatson@freebsd.org> Cc: arch@freebsd.org, kmacy@freebsd.org, net@freebsd.org Subject: Re: Network device driver KPI/ABI and TOE Message-ID: <7ive61uwfm.wl%gnn@neville-neil.com> In-Reply-To: <20080106124517.G105@fledge.watson.org> References: <20080106124517.G105@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At Sun, 6 Jan 2008 13:47:24 +0000 (GMT), rwatson 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? > Given the intimacy that I just perused in the code, basically the driver knows a lot about internal TCP data structures, I think we need to think about a kernel KPI just for these things. I'm not very happy that there are things like cxgb_tcp_ctlinput() although I do know that cleaning that kind of thing up and making a better KPI will be hard. Best, George
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7ive61uwfm.wl%gnn>