From owner-freebsd-arch@FreeBSD.ORG Sun Jan 6 21:22:07 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F03B16A41A for ; Sun, 6 Jan 2008 21:22:07 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id 34DE713C46B for ; Sun, 6 Jan 2008 21:22:07 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so4885176fgg.35 for ; Sun, 06 Jan 2008 13:22:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=UjHAisz+SN1VuzeWsiMWnN5ZkDfyUdMj/Ivt6b53I/U=; b=NsRUvMmfcK5MNcaY5GQf1wNIYc7TJzAcAxqaC1o++QLJ5gSWg1NyRKMkexFE2JbIzMnouhmq0LEARNhY3Hou43MVh0/6nUO6R+2ch7BWG5OK6Xm5LDOEErkJ3PzwmK453htwHNZQn9eek2h3QxUAlNG7SAl5NuXRO/AY5BYudGU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XGCYEpiM+KHSBeOC8Xgo3qJI/nSS3k8LjbQr1fLTWBfHTea83WN0qn0AFgg8Rid3Inxn7ggqoQlgSEZzgrGYZt+czA39B8ZPNzjqMcMYkbI209NtuM1p2PyfJVeIp4jz6a+Cdkm9YPYaR/yFwxdc7oJiS0zYkwnYWIwpBNx8FJ8= Received: by 10.86.79.19 with SMTP id c19mr19372527fgb.31.1199653010854; Sun, 06 Jan 2008 12:56:50 -0800 (PST) Received: by 10.86.98.15 with HTTP; Sun, 6 Jan 2008 12:56:50 -0800 (PST) Message-ID: <2a41acea0801061256j867053dq69b46664e0283b3e@mail.gmail.com> Date: Sun, 6 Jan 2008 12:56:50 -0800 From: "Jack Vogel" To: "Robert Watson" In-Reply-To: <20080106124517.G105@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080106124517.G105@fledge.watson.org> Cc: arch@freebsd.org, kmacy@freebsd.org, net@freebsd.org Subject: Re: Network device driver KPI/ABI and TOE 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: Sun, 06 Jan 2008 21:22:07 -0000 On Jan 6, 2008 5:47 AM, Robert Watson wrote: ... > My proposal, and this is really a proposal to drive discussion as much as a > proposal for a policy, is that the internal TCP data structures exported via > the TOE interfaces and accessed by TOE device drivers *not* be considered > ABI/KPI-stable in -STABLE branches. While I think we shouldn't intentionally > change them to break TOE, it's unrealistic to expect that these network stack > internals won't change as part of normal maintenance and feature development > that take place in -STABLE branches. > > For those who aren't involved in those day-to-day internals, a comparable > situation might be if a CAM SCSI storage driver was dependent not only on > there being no changes made to the on-disk layout of UFS (even backwards > compatible ones), but also the in-memory data structures of soft updates. Any > significant changes to soft updates internals would break such device drivers > due to a requirement for forward compatibility. In some ways this isn't a > perfect comparison, as soft updates isn't under active development, but from a > layering and abstraction perspective, it's quite similar. > > We don't yet ship TOE in a -STABLE branch, but I believe Kip hopes to MFC TOE > support, and with other device driver vendors starting to take a look, I think > we want out thoughts on the table regarding this matter. I presume that we'll > see the TOE interfaces continue to evolve over the next 6-18 months, and we > should make sure that we know whether or not third party device driver authors > can expect ABI/KPI stability before, rather than after, it hits a -STABLE > branch. On a similar note, these necessary changes to network stack internals > will result in modifications to in-tree device drivers, so device driver > authors who implement TOE should expect to see the TOE parts of their drivers > being significantly modified as development occurs on those other parts of the > stack. > > 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? I agree Robert, I have hit minor KPI changes during the 6.X evolution and found them annoying. On the other hand, I know what its like when a company has hardware and wants support for it :) Is it perhaps a possible compromise to put in support but leave it defined off by default? Happy New Year BTW :) Jack