Netdev List
 help / color / mirror / Atom feed
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.


  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