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

Powered by blists - more mailing lists