From: Ben Hutchings <bhutchings@solarflare.com>
To: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>
Cc: netdev@vger.kernel.org,
Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>,
e1000-devel@lists.sourceforge.net
Subject: Re: Broken TX checksumming offloads
Date: Mon, 29 Nov 2010 19:13:23 +0000 [thread overview]
Message-ID: <1291058003.20703.16.camel@bwh-desktop> (raw)
In-Reply-To: <20101129181742.GA29192@rere.qmqm.pl>
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.
Older kernel versions lacked a definititon of NETIF_F_IPV6_CSUM so
out-of-tree drivers and in-tree drivers that started out-of-tree are
likely to use NETIF_F_HW_CSUM as a workaround for that.
Since the minimum size of a {TCP,UDP}/IPv6/Ethernet frame is 62 bytes +
CRC, the workaround in pch_gbe_tx_queue() may not be needed for IPv6.
(I'm assuming that the critical length of 64 bytes actually includes the
CRC, although the workaround code currently assumes otherwise.)
> This means that these drivers might send packets with broken checksums
> when TX checksumming offload is enabled. I haven't checked other drivers, yet.
They might or they might not; it's hard to tell without access to the
hardware. But if the driver never references csum_{start,offset} then
it is probably valid to replace NETIF_F_HW_CSUM with NETIF_F_IP_CSUM |
NETIF_F_IPV6_CSUM (and similarly for the ethtool operations).
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
next prev parent reply other threads:[~2010-11-29 19:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-29 18:17 Broken TX checksumming offloads Michał Mirosław
2010-11-29 19:13 ` Ben Hutchings [this message]
2010-11-30 2:35 ` Jesse Gross
2010-11-30 14:23 ` MichałMirosław
2010-11-30 14:23 ` [PATCH] net: Move check of checksum features to netdev_fix_features() MichałMirosław
2010-11-30 14:23 ` [PATCH] net: Fix too optimistic NETIF_F_HW_CSUM features MichałMirosław
[not found] ` <1291130005.21077.18.camel@bwh-desktop>
2010-11-30 15:28 ` MichałMirosław
2010-11-30 15:41 ` Michał Mirosław
2010-11-30 16:12 ` Jon Mason
2010-11-30 15:51 ` Ben Hutchings
2010-11-30 16:18 ` MichałMirosław
2010-11-30 16:38 ` [PATCH v2] " MichałMirosław
2010-11-30 16:53 ` Eric Dumazet
2010-11-30 17:07 ` MichałMirosław
2010-11-30 17:15 ` MichałMirosław
2010-11-30 17:17 ` Eric Dumazet
2010-12-02 0:44 ` Jon Mason
2010-12-06 21:01 ` David Miller
2010-11-30 14:23 ` [PATCH] net: Fix drivers advertising HW_CSUM feature to use csum_start MichałMirosław
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1291058003.20703.16.camel@bwh-desktop \
--to=bhutchings@solarflare.com \
--cc=e1000-devel@lists.sourceforge.net \
--cc=mirq-linux@rere.qmqm.pl \
--cc=netdev@vger.kernel.org \
--cc=toshiharu-linux@dsn.okisemi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox