From owner-freebsd-arch@FreeBSD.ORG Tue Jan 8 22:23: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 A549D16A417 for ; Tue, 8 Jan 2008 22:23:07 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 263DE13C459 for ; Tue, 8 Jan 2008 22:23:06 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 76409 invoked from network); 8 Jan 2008 21:47:16 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Jan 2008 21:47:16 -0000 Message-ID: <4783F7CE.5060600@freebsd.org> Date: Tue, 08 Jan 2008 23:23:10 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Peter Jeremy References: <20080106124517.G105@fledge.watson.org> <47811904.4060300@elischer.org> <20080106182340.K105@fledge.watson.org> <20080107091006.GN947@server.vk2pj.dyndns.org> In-Reply-To: <20080107091006.GN947@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Robert Watson 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: Tue, 08 Jan 2008 22:23:07 -0000 Peter Jeremy wrote: > On Sun, Jan 06, 2008 at 06:37:19PM +0000, Robert Watson wrote: >> What I'm more concerned about is the new exposure of internal data >> structures and algorithms, and a resulting freeze of those data structures >> and algorithms if we were to apply our current ABI/PI policy to the TOE >> interfaces. > > Whilst I doubt TOE will directly affect me in the short term, I would be > disappointed if general TCP improvements could not be MFCd because it > would change the TOE ABI. > > I believe that TOE is fairly new and not completely mature feature. > Is it possible that further experience with TOE may also lead to > changes in the interfaces between TOE and the rest of the kernel, > irrespective of the kernel innards? Certainly. I agree with Robert that we should not guarantee a stable TOE KPI/ABI yet. TOE is a relatively young technology and so far we've only seen one hardware for it together with its assumptions and implementation issues. It is also way more complex than simpler features than checksum offloading or segmentation offloading. IMHO we should not make it fully stable unless we've gained more experience with it and also a second or third hardware making use of it with perhaps slightly differing assumptions and requirements. OTOH there shouldn't be any deliberate breakage of TOE without a good justification for it. -- Andre