Network device driver KPI/ABI and TOE

[Kip Macy]

On Jan 10, 2008 2:50 PM,  <gnn at 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