netdev - Re: Checksum offload queries

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 9 Dec 2015 23:29:24 +0100
From:	Thomas Graf <tgraf@...g.ch>
To:	Tom Herbert <tom@...bertland.com>
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 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.

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