Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 23 May 2012 13:52:55 +0530
From:      Venkat Duvvuru <venkatduvvuru.ml@gmail.com>
To:        lstewart@freebsd.org
Cc:        freebsd-net@freebsd.org, "Bjoern A. Zeeb" <bz@freebsd.org>, freebsd-questions@freebsd.org, Jack Vogel <jfvogel@gmail.com>
Subject:   Re: LRO support for IPv6
Message-ID:  <CAGdae7bx48Q8nk0Qf%2BKwMb9kcCcsvK_VG5N5_iGxhxDpMwV=gQ@mail.gmail.com>
In-Reply-To: <CAGdae7a%2Baf7RbijyKfMA94MfomNaTaD3M3PPmcFk%2B13SC9cMAg@mail.gmail.com>
References:  <CAGdae7bcWqGbObygPdZwCyVG4Pe-0Fxq5_p19oCp61uzZ4N8xw@mail.gmail.com> <CAFOYbc=ng83L8iZ_N79edqhknOrDPqVA9ASMexW5-yU0vnduDQ@mail.gmail.com> <A8DB9672-6B84-4635-84B6-43CC98B2877F@FreeBSD.org> <CAFOYbckwRw4jazwqY1S7X2wiSdBBBPdg-Xk8ya99j1%2BWbqB=DA@mail.gmail.com> <72B744D5-3D24-4A56-907C-2A8F6620877B@FreeBSD.org> <CAGdae7ZX4M4NPnJ=3K1vA9TLPW22r2EpTic-Y4kJMyJQGn3zGw@mail.gmail.com> <CAFOYbcncAGPA6d7qh7bonGy2ijcApD_TQgqvSoM2Mbif-z8sYg@mail.gmail.com> <CAGdae7a%2Baf7RbijyKfMA94MfomNaTaD3M3PPmcFk%2B13SC9cMAg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Folks,
Can somebody please explain me why "tcp checsum" calculation is mandated in
the freebsd network stack (tcp_input--->in6_cksum) albeit the card supports
it?

Probably Steve is the right person who can answer this.

/Venkat

On Wed, May 23, 2012 at 11:27 AM, Venkat Duvvuru <venkatduvvuru.ml@gmail.com
> wrote:

> Ok. I found the reason for the throughput drop in case of IPv6.
> Reason is that the "tcp check sum" calculation is mandated in case of IPv6
> irrespective of whether the card is doing it or not (checksum offload). Is
> there a reason why freebsd is doing it that way?
>
> /Venkat
>
>  On Tue, May 22, 2012 at 11:16 PM, Jack Vogel <jfvogel@gmail.com> wrote:
>
>> LRO is a huge win for 10G (as is TSO on the TX side), so odds are good
>> its behind the drop,
>> in any case you'll be able to test that soon :)
>>
>> Jack
>>
>>
>>
>> On Tue, May 22, 2012 at 10:35 AM, Venkat Duvvuru <
>> venkatduvvuru.ml@gmail.com> wrote:
>>
>>> Thanks for the response.
>>>
>>> I observed that there is a significant performance drop in case of IPv6
>>> on the "rx" side.
>>> While I'm able to hit line rate ~9.5 Gbps on a 10gb NIC for IPv4..I
>>> could only get ~6 Gbps on the "rx" front for IPv6...However "tx" for IPv6
>>> is on par with IPv4 hitting almost line rates.
>>>
>>> Could this be because of lack of LRO6??
>>>
>>> Note: hwpmc profiling shows that most of the time is spent in the IPv6
>>> stack code
>>>
>>> /Venkat
>>>  On Tue, May 22, 2012 at 10:37 PM, Bjoern A. Zeeb <bz@freebsd.org>wrote:
>>>
>>>>
>>>> On 22. May 2012, at 17:04 , Jack Vogel wrote:
>>>>
>>>> > Oh, that's right, distracted with other projects and I forgot, now we
>>>> just need
>>>> > to have an LRO that works with forwarding eh :)
>>>>
>>>> That's a 6 line bainaid commit afterwards, basically returning form the
>>>> LRO queuing
>>>> function in case forwarding is turned on for that address family;  a
>>>> proper solution
>>>> for long term can than be done whenever we feel like it.  The above we
>>>> should have done
>>>> years ago;)
>>>>
>>>>
>>>> > You ROCK bz :)
>>>> >
>>>> > Jack
>>>> >
>>>> >
>>>> > On Tue, May 22, 2012 at 10:01 AM, Bjoern A. Zeeb <bz@freebsd.org>
>>>> wrote:
>>>> >
>>>> > On 22. May 2012, at 16:50 , Jack Vogel wrote:
>>>> >
>>>> > > The LRO code as it stands right now is IPV4 specific, it would be
>>>> nice to
>>>> > > extend it, one of
>>>> > > many improvements that may get done at some point.
>>>> >
>>>> > I am about to commit it to HEAD.  Bear another few days with me; I
>>>> know
>>>> > I am running late but committing new code had less prio than some
>>>> other
>>>> > real life things currently.
>>>> >
>>>> > I'll also bring TSO6, etc...
>>>>
>>>>  --
>>>> Bjoern A. Zeeb                                 You have to have visions!
>>>>   It does not matter how good you are. It matters what good you do!
>>>>
>>>>
>>>
>>
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGdae7bx48Q8nk0Qf%2BKwMb9kcCcsvK_VG5N5_iGxhxDpMwV=gQ>