[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALx6S34ns4e_zNzGT6wa9Un7v+P1BiY62UaDCTmS2NeQ_BpBQg@mail.gmail.com>
Date: Wed, 9 Dec 2015 14:51:42 -0800
From: Tom Herbert <tom@...bertland.com>
To: Thomas Graf <tgraf@...g.ch>
Cc: Edward Cree <ecree@...arflare.com>,
David Miller <davem@...emloft.net>,
Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: Checksum offload queries
On Wed, Dec 9, 2015 at 2:29 PM, Thomas Graf <tgraf@...g.ch> wrote:
> On 12/09/15 at 08:08am, Tom Herbert wrote:
>> On Tue, Dec 8, 2015 at 5:56 PM, Thomas Graf <tgraf@...g.ch> wrote:
>> > If I understood Edward correctly, his proposal would be for the
>> > card to provide both, the csum as for CHECKSUM_COMPLETE plus the
>> > validation yes/no hint. It would be up to the kernel to decide
>> > whether to validate itself or trust the card.
>> >
>> > I'm all in favour CHECKSUM_COMPLETE as the only way to go but
>> > we should be aware that it depends on the penetration of RCO in
>> > hardware VTEPs.
>>
>> Thomas, I don't understand what you are saying here. CHECKSUM_COMPLETE
>> is an interface for drivers providing the computed checksum of a
>> packet on receive, how is this dependent on any use case or any other
>> mechanisms?
>
> I'm referring to the overall change which comes with a pure
> CHECSUM_COMPLETE model which would forbid a NIC to do automatic nested
> checksum filling even if untold. RCO solves that to some extent but
> only if RCO is widely supported. I'm not aware of anybody relying on
> the performance of such hardware yet so I doubt we would create a
> performance regression.
>
I'm sorry, I still don't understand your point. What is "automatic
nested checksum filling" and how does this relate to RX (e.g.
CHECSUM_COMPLETE).
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists