From owner-freebsd-arch@FreeBSD.ORG Sat Dec 15 22:47:13 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6613116A479; Sat, 15 Dec 2007 22:47:13 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id E719813C4F0; Sat, 15 Dec 2007 22:47:12 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id lBFMl0Z7085175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Dec 2007 14:47:00 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <47645963.40301@errno.com> Date: Sat, 15 Dec 2007 14:46:59 -0800 From: Sam Leffler User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Kevin Oberman References: <20071215224101.6D1A045013@ptavv.es.net> In-Reply-To: <20071215224101.6D1A045013@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-dcc-servers-Metrics: om; whitelist Cc: FreeBSD Current , freebsd-arch@freebsd.org Subject: Re: pending changes for TOE support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 22:47:13 -0000 Kevin Oberman wrote: >> Date: Sat, 15 Dec 2007 14:02:28 -0800 >> From: "Kip Macy" >> Sender: owner-freebsd-current@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. Sam