Kevin Oberman wrote: >> 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. > So far as I know none of Intel, Myricom, and Neterion support TOE. SamReceived on Sat Dec 15 2007 - 21:47:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:24 UTC