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]

Message-ID: <5666EC4B.40800@solarflare.com>
Date:	Tue, 8 Dec 2015 14:42:19 +0000
From:	Edward Cree <ecree@...arflare.com>
To:	David Miller <davem@...emloft.net>
CC:	<netdev@...r.kernel.org>, Tom Herbert <tom@...bertland.com>
Subject: Re: Checksum offload queries

On 07/12/15 19:38, David Miller wrote:
> No, it is better to universally provide the 1's complement sum for
> all receive packets.  This allows the stack more flexibility in
> checksum handling.
I'm afraid I still don't see it.  If a device can both provide the 1's complement sum _and_ validate some of the checksums in the packet, that should be strictly better than just providing the 1's complement sum - the stack has at least as much information, and less work to do.  And while there is no general way at present for a driver to tell the stack it has done both (and in my opinion there should be such a way), it _is_ possible in the specific case of a UDP packet with the checksum filled in, thanks to CHECKSUM_UNNECESSARY conversion.  So why shouldn't a device (that otherwise gives the full ones complement sum with CHECKSUM_COMPLETE) use CHECKSUM_UNNECESSARY in this specific case?  Is there a flaw in my logic, or is it just that this would be a hack and the Right Thing is to change the interface to let a driver report both pieces of information *directly*?  Or am I wrong for some other reason?
>> 3) Related to the above, what does a NETIF_F_HW_CSUM device do when
>> transmitting an unencapsulated packet
> The stack will have skb->csum_start point to the UDP header's checksum
> field for unencapsulated packets, and it has done this for decades.
>
> Sun Microsystems had NETIF_F_HW_CSUM supporting NICs nearly two
> decades ago, and this is what NETIF_F_HW_CSUM was designed for.
Thanks, that makes more sense now.  Though, does that mean that there's no way in this case to offload the IP header checksum?  (Of course, it's generally much less work than the payload checksum, and it goes away in v6.)

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