Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Jun 2009 10:56:31 +0000 (UTC)
From:      "Bjoern A. Zeeb" <bz@FreeBSD.org>
To:        Pyun YongHyeon <pyunyh@gmail.com>
Cc:        FreeBSD net mailing list <freebsd-net@freebsd.org>, "George V. Neville-Neil" <gnn@freebsd.org>, Michael Tuexen <tuexen@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:  <20090612100900.M22887@maildrop.int.zabbadoz.net>
In-Reply-To: <20090612013406.GB72855@michelle.cdnetworks.co.kr>
References:  <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr>

next in thread | previous in thread | raw e-mail | index | archive | help
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)?


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?

 	We do have CSUM_IP, CSUM_TCP, CSUM_UDP, CSUM_SCTP.
 	What will that be?

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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090612100900.M22887>