From owner-freebsd-net@FreeBSD.ORG Sat Jun 13 08:50:08 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 475B9106566B; Sat, 13 Jun 2009 08:50:08 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id CA6308FC19; Sat, 13 Jun 2009 08:50:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 65DE841C735; Sat, 13 Jun 2009 10:50:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id ZgrLVfaFPcmc; Sat, 13 Jun 2009 10:50:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id EF8F341C71D; Sat, 13 Jun 2009 10:50:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id B3D104448E6; Sat, 13 Jun 2009 08:48:39 +0000 (UTC) Date: Sat, 13 Jun 2009 08:48:39 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Michael Tuexen In-Reply-To: <7472C82E-0C52-45AB-9BFF-DD6196B393C9@freebsd.org> Message-ID: <20090613084513.L22887@maildrop.int.zabbadoz.net> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <71535CB2-2784-4253-B67E-017FEAD57637@freebsd.org> <4A32F752.90003@cs.duke.edu> <20090613080136.GB76872@michelle.cdnetworks.co.kr> <7472C82E-0C52-45AB-9BFF-DD6196B393C9@freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: pyunyh@gmail.com, FreeBSD net mailing list , Andrew Gallatin Subject: Re: Ethernet NIC drivers depending unconditionally on INET X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 08:50:08 -0000 On Sat, 13 Jun 2009, Michael Tuexen wrote: > On Jun 13, 2009, at 10:01 AM, Pyun YongHyeon wrote: > >> On Sat, Jun 13, 2009 at 09:15:06AM +0200, Michael Tuexen wrote: >>> On Jun 13, 2009, at 2:48 AM, Andrew Gallatin wrote: >>> >>>> Michael Tuexen wrote: >>>> >>>>> I'm not sure if we need additional IFCAP_RXCSUM6 IFCAP_TXCSUM6 >>>>> capabilities... Why would we want to enable IPv4 offloading and >>>>> not IPv6 or vice versa? >>>> >>>> I'd assume that some older hardware supports IPv4 offloads, but >>>> might not have support for IPv6 offloads. >>> Sure. But then the driver only provides the CSUM_ flags which >>> are appropriate. For example, a similar thing is already in the >>> igb driver: >>> >>> 1167 if (ifp->if_capenable & IFCAP_TXCSUM) { >>> 1168 ifp->if_hwassist |= (CSUM_TCP | CSUM_UDP); >>> 1169 #if __FreeBSD_version >= 800000 >>> 1170 if (adapter->hw.mac.type == e1000_82576) >>> 1171 ifp->if_hwassist |= CSUM_SCTP; >>> 1172 #endif >>> 1173 } >> >> That would disable all IPv4/IPv6 checksum offloading if >> administrator disable IFCAP_TXCSUM. If we have IFCAP_TXCSUM6/ >> IFCAP_RXCSUM6 users could choose best working one even if some part >> of driver/controller had checksum offload bugs. > Sure. That is what I wrote in my earlier mail: Do we want to > provide a ability to disable/enable checksum offload for > IPv4 and IPv6 individually... > Besides this "working around bugs" I see no reason to do > it. Some other capabilities TSO/TOE are IPv[46] specific. > I have no strong opinion on this. What do others think? I think if there are bugs the driver would have to make sure to handle if_hwassist appropriately ; actually we are already doing this. Often it would be chip revision specific I guess so it doesn't really make sense to break it down to IPv4/v6. Either you turn it on and get what the driver thinks this chip can do or you don't get any. If there is a bug for a chip revision, enhance the driver to know to handle it correctly and be done. Actuallt that is exactly what you sample above is doing - enabling CSUM_SCTP only for a specific chip. /bz -- Bjoern A. Zeeb The greatest risk is not taking one.