Re: pending changes for TOE support

> Date: Sat, 15 Dec 2007 14:02:28 -0800
> From: "Kip Macy" <kip.macy_at_gmail.com>
> Sender: owner-freebsd-current_at_freebsd.org
> 
> > I think we should make a best faith effort to figure out how to do the right
> > thing.  Employing harsh interrogation tactics is probably not called for, but
> > we have several vendors who are regularly involved in the FreeBSD community
> > and may be willing to lend their insight as to their requirements, even if an
> > implementation isn't immediately forthcoming.
> 
> :-) - the two vendors that I know of have not been active in the
> community. Sam has initiated contact on my behalf with the one vendor
> that might be willing to talk to us. The other vendor has an
> established pattern of ignoring all requests.
> 
> >
> > >> tcp_output() was previously an internal function of the TCP code, and now
> > >> the semantics are being exposed to device drivers.  Let's not perpetuate
> > >> poorly documented driver interfaces by adding another one.  I think it
> > >> would be a reasonable expectation of a driver author to have consistent
> > >> documentation of the life cycle of data structures and objects, locking
> > >> expectations and requirements, and the semantics for error values from
> > >> functions.  Certainly, they need to look at TCP a fair amount because
> > >> they'll be pulling things out of inpcb, tcpcb, etc, but I'd rather we limit
> > >> that requirement to simple things (addresses, socket options) that are
> > >> relatively static and avoid it being for complex things (locking, error
> > >> handling) that tend to be more subject to change.  Also, if you document
> > >> what you think the behavior is or should be, we can then check to see if we
> > >> agree.
> > >
> > > To the extent possible, yes. I'm not convinced that anyone person knows what
> > > all the existing invariants are in the stack as it is now. Do you feel that
> > > a Stevens'-esque understanding of the environment around the calls is
> > > necessary? I know it sounds like "other people beat their wives so I can
> > > too", but even something as well documented as ifnet gives no indication of
> > > what the locking conventions - e.g. you can't sleep or acquire sx locks in
> > > if_ioctl. The demands placed should be no greater than those placed on
> > > existing subsystems and should take into account the hitherto somewhat black
> > > box nature of TCP.
> >
> > Actually, what I was asking for in the omitted context above was something
> > along the lines of the following, adapted for whatever the reality may be:
> >
> >    Returning a non-zero value will lead to the software stack beginning a
> >    disconnect.
> >
> > Or, say,
> >
> >    Non-zero return values will be ignored. (*)
> >
> > This is not intended as a contrarian point.  I'm not looking for a complete
> > exposition of the behavior of the stack -- rather, basic information that we
> > should be documenting about a KPI, such as what an error being returned will
> > do.
> 
> That is quite reasonable. I perceived your initial request as being
> entirely too open-ended.

We certainly know who provides support for Intel and Myricom cards
(unless there has been a recent change of which I am unaware) and I
happen to work across the hall from the guy who has been upgrading the
Neterion drivers for them and I suspect provided the recent new versions
to them.

Am I missing anyone?

If they are contacted and express disinterest or don't respond, I think
Kip has to proceed as best he can.

We use three of the vendors I know of with FreeBSD, so can push as a
customer, too. We will be ordering more 10GE cards from someone soon and
support for TOE could be a significant issue in selection. Until now it
has not been mentioned since there was no prospect of near-term FreeBSD
support, but that is clearly no longer the case.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman_at_es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751