From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 21:16:01 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 EBD0D106564A; Fri, 12 Jun 2009 21:16:01 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from dvz-002.fh-muenster.de (dvz-002.FH-Muenster.DE [193.174.88.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6C10E8FC0A; Fri, 12 Jun 2009 21:16:01 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by dvz-002.fh-muenster.de (Postfix) with ESMTP id 195781CC4EA; Fri, 12 Jun 2009 22:55:58 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at dvz-002.fh-muenster.de X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=6.31 tests=[ALL_TRUSTED=-1.665, BAYES_00=-2.312] Received: from dvz-002.fh-muenster.de ([127.0.0.1]) by localhost (dvz-002.fh-muenster.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDfzrqFCTcv9; Fri, 12 Jun 2009 22:55:56 +0200 (CEST) Received: from [192.168.1.100] (p508FEA6E.dip.t-dialin.net [80.143.234.110]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: tuexen) by dvz-002.fh-muenster.de (Postfix) with ESMTP id A33431CC4C9; Fri, 12 Jun 2009 22:55:55 +0200 (CEST) Message-Id: <71535CB2-2784-4253-B67E-017FEAD57637@freebsd.org> From: Michael Tuexen To: Bjoern A. Zeeb In-Reply-To: <20090612100900.M22887@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 22:57:56 +0200 References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> X-Mailer: Apple Mail (2.935.3) Cc: Pyun YongHyeon , FreeBSD net mailing list , "George V. Neville-Neil" , Navdeep Parhar , Andrew Thompson , Jack F Vogel , Andrew Gallatin , Pyun YongHyeon 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: Fri, 12 Jun 2009 21:16:02 -0000 On Jun 12, 2009, at 12:56 PM, Bjoern A. Zeeb wrote: > On Fri, 12 Jun 2009, Pyun YongHyeon wrote: > > Hi, > >> Yeah, there are no checksum offloading support for IPv6 under >> FreeBSD so there are no cases the frames are IPv6 when >> CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set. > > The thing that scared me was sys/netinet/tcp_subr.c:tcp_maxmtu6(). > > What I had missed was the CSUM_TSO6 (the 6 at the end) part. > grepping through the tree I am even wondering a lot more now when I > see what cxgb(4) is doing with that;) > > >>> In case you are maintaining another driver but cannot find it on the >>> list - be sure we'll find you during the 9.x lifecycle in case you >>> do >>> not properly handle things;-) >>> >> >> [ list of drivers part removed ] >> >> I guess you missed hme(4) and gem(4) in the list and most old > > Nope, both have a hand crafted way of computing the cksums; not sure > if that is good or bad; I guess the latter but with that they were not > running into the INET dependency problematic I cared about in this > pass. > > >> hardwares that supports checksum offloading have no capability to >> handle IPv6 checksum offloading. If we do not define appropriate >> capabilities(IFCAP_RXCSUM_IPV4, IFCAP_TXCSUM_IPV6, >> IFCAP_RXCSUM_TCPV4, IFCAP_TXCSUM_TCPV6 etc) first it would be >> hard to change code, I guess. > > There is no such things as an IPv6 cksum. For IPv6 you only care about > ULPs. > > > I am not entirely sure (as in I forgot; it's been a month;) but > Michael Tuexen (new comitter) is working on the proper flags im along > with one for SCTP; The part I am usure about was if he only cared > about CSUM first and not IFCAP but really both have to come along. > > What was the plan here? Michael, can you fill this gap (perhaps > below)? Sure. See my comments below. > > > To also address Drew's question: > >> As a sort of side-note, what about feature parity for INET6 for >> existing IPV4 features like TSO? Who is working on that? > > Ok, maybe we should write down the big list now. What all can we have? > What do we already have? What do we need? What needs to be changed? > > IPv4 CSUM offloading > ULP (TCP|UDP|SCTP) CSUM offloading v4/v6 > We do have IFCAP_RXCSUM,IFCAP_TXCSUM but that means a > different CSUM_* subset for each card, right? Yes. Currently some driver would do CSUM_IP|CSUM_TCP|CSUM_UDP. The igb driver currently does CSUM_IP|CSUM_TCP|CSUM_UDP|CSUM_SCTP. > > We do have CSUM_IP, CSUM_TCP, CSUM_UDP, CSUM_SCTP. > What will that be? I think we should keep CSUM_IP, CSUM_TCP, CSUM_UDP, CSUM_SCTP which are for IPv4. In addition we need new flags CSUM_TCP6, CSUM_UDP6, CSUM_SCTP6 which are only for IPv6. After the change the igb driver would announce CSUM_IP|CSUM_TCP|CSUM_UDP|CSUM_SCTP|CSUM_TCP6|CSUM_UDP6|CSUM_SCTP6. The network layer and transport layer has to be changed accordingly. My plan is to provide the infrastructure and test it with the igb driver. After that is in the repository, other drivers have to be changed to announce their appropriate capabilities. 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? > > TSO v4/v6 > We do have IFCAP_TSO4|IFCAP_TSO6 > > We do have CSUM_TSO, so that should become CSUM_TSO4 and we'll > need to add CSUM_TSO6? > > LRO v4/v6 (is anyone doing or planning to and can talk about it, > LRO v6?) > We do have IFCAP_LRO. > > TOE -- how much is that tied into IPv4/v6 and how much general > infrastructure, rather than per-card, could a world need? > We do have IFCAP_TOE = (IFCAP_TOE4|IFCAP_TOE6) > > > /bz > > -- > Bjoern A. Zeeb The greatest risk is not taking > one. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >