Date: Thu, 10 Jan 2008 14:56:32 -0800 From: "Kip Macy" <kip.macy@gmail.com> To: gnn@freebsd.org Cc: arch@freebsd.org, Robert Watson <rwatson@freebsd.org>, kmacy@freebsd.org, net@freebsd.org Subject: Re: Network device driver KPI/ABI and TOE Message-ID: <b1fa29170801101456l38b3809cs40a880572532ce05@mail.gmail.com> In-Reply-To: <7ive61uwfm.wl%gnn@neville-neil.com> References: <20080106124517.G105@fledge.watson.org> <7ive61uwfm.wl%gnn@neville-neil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 10, 2008 2:50 PM, <gnn@freebsd.org> wrote: > 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. Although you are correct in the need for a more thought out KPI, that is actually not a good example. Although the way it is currently implemented is not multi-TOE friendly tcp_ctlinput is the correct way to extend socket options. A better example is the way it needs to know the specifics of not only the tcpcb, but the inpcb, and parts of the socket as well. By extension it needs to understand the subtleties of inpcb and pcbinfo locking. This is, needless to say, quite fragile. -Kip
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b1fa29170801101456l38b3809cs40a880572532ce05>