Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Jun 2009 22:57:56 +0200
From:      Michael Tuexen <tuexen@freebsd.org>
To:        Bjoern A. Zeeb <bz@FreeBSD.org>
Cc:        Pyun YongHyeon <pyunyh@gmail.com>, FreeBSD net mailing list <freebsd-net@freebsd.org>, "George V. Neville-Neil" <gnn@freebsd.org>, Navdeep Parhar <np@FreeBSD.org>, Andrew Thompson <thompsa@freebsd.org>, Jack F Vogel <jfv@freebsd.org>, Andrew Gallatin <gallatin@freebsd.org>, Pyun YongHyeon <yongari@freebsd.org>
Subject:   Re: Ethernet NIC drivers depending unconditionally on INET
Message-ID:  <71535CB2-2784-4253-B67E-017FEAD57637@freebsd.org>
In-Reply-To: <20090612100900.M22887@maildrop.int.zabbadoz.net>
References:  <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net>

next in thread | previous in thread | raw e-mail | index | archive | help

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"
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?71535CB2-2784-4253-B67E-017FEAD57637>