From owner-freebsd-arch@FreeBSD.ORG Sat Dec 15 22:41:04 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 F21F016A418; Sat, 15 Dec 2007 22:41:03 +0000 (UTC) (envelope-from SRS0=175ffd958ccf631e3f50bc84e4580880c9a9c317=550=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id 437A213C44B; Sat, 15 Dec 2007 22:41:03 +0000 (UTC) (envelope-from SRS0=175ffd958ccf631e3f50bc84e4580880c9a9c317=550=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id UIE67201; Sat, 15 Dec 2007 14:41:01 -0800 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 6D1A045013; Sat, 15 Dec 2007 14:41:01 -0800 (PST) To: "Kip Macy" In-Reply-To: Your message of "Sat, 15 Dec 2007 14:02:28 PST." Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1197758461_12041P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sat, 15 Dec 2007 14:41:01 -0800 From: "Kevin Oberman" Message-Id: <20071215224101.6D1A045013@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; ; X-Sender: X-To_Name: Kip Macy X-To_Domain: gmail.com X-To: "Kip Macy" X-To_Email: kip.macy@gmail.com X-To_Alias: kip.macy Cc: FreeBSD Current , Robert Watson , 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:41:04 -0000 --==_Exmh_1197758461_12041P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > 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. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1197758461_12041P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFHZFf9kn3rs5h7N1ERAitpAJ9mP+hrmQPP71rmVJe+Hd4b22hkWgCgh7Lm zAZZ2t/fF9qf42P9u8mz3j0= =qjFn -----END PGP SIGNATURE----- --==_Exmh_1197758461_12041P--