netdev - Re: Broken TX checksumming offloads

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <AANLkTi=U51Y7rsQXr+_6TreUks_MyRMdRU=TtdxKOG2Z@mail.gmail.com>
Date:	Mon, 29 Nov 2010 18:35:44 -0800
From:	Jesse Gross <jesse@...ira.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
Cc:	Michał Mirosław <mirq-linux@...e.qmqm.pl>,
	netdev@...r.kernel.org,
	Toshiharu Okada <toshiharu-linux@....okisemi.com>,
	e1000-devel@...ts.sourceforge.net
Subject: Re: Broken TX checksumming offloads

2010/11/29 Ben Hutchings <bhutchings@...arflare.com>:
> On Mon, 2010-11-29 at 19:17 +0100, Michał Mirosław wrote:
>> Hi!
>>
>> Unless I'm horribly mistaken, generic HW checksumming works as follows:
>>  - driver sets netdev->features & NETIF_F_HW_CSUM to indicate support
>>    for generic checksumming; if the flag is not set, networking core
>>    will checksum skb before calling ndo_start_xmit (let's ignore
>>    other checksumming options for now) and not pass skb with
>>    skb->ip_summed == CHECKSUM_PARTIAL
>>  - ndo_start_xmit() should use skb->csum_start and skb->csum_offset
>>    (or skb->csum) to update checksum in software or instruct HW to do so
>>
>> Looking at pch_gbe_xmit_frame() and its callee - pch_gbe_tx_queue() it
>> looks like the driver should set NETIF_F_IP_CSUM instead of NETIF_F_HW_CSUM
>> feature.
>>
>> Similar thing happens in ixgbe driver: it sets NETIF_F_HW_CSUM and checks
>> for skb->ip_summed == CHECKSUM_PARTIAL, but then just warns on protocols
>> other that TCP and SCTP (see: ixgbe_psum()).
>
> AFAIK only {TCP,UDP}/IPv{4,6} use the simple 16-bit checksum algorithm
> that NETIF_F_HW_CSUM implies, so in practice it is equivalent to
> NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM even though it doesn't mean the same
> thing.

There are a few cases that I can think of where the extra generality
of NETIF_F_HW_CSUM is useful:

* The checksum in GRE (maybe other protocols as well) uses the same
algorithm as TCP/UDP.  In theory this means that we could use hardware
offloading for GRE on cards that have NETIF_F_HW_CSUM.  The one issue
is that NETIF_F_IP_CSUM really means TCP/UDP checksumming but we only
test if the protocol is IP.  This means that other IP based protocols
(like GRE) can't use checksum offloading since there is no software
fallback path.

* TCP/UDP packets that are deeply encapsulated.  Currently we can
express that checksum offloading is supported in one level of vlan
encapsulation through vlan_features.  However, a NIC that exposes
NETIF_F_HW_CSUM should in theory be able to checksum over a packet
that has an arbitrary number of vlan tags in front of it, a GRE
header, or any other type of encapsulation.
--
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