All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@linux-foundation.org>
To: Herbert Xu <herbert.xu@redhat.com>
Cc: netdev@vger.kernel.org, Michael Chan <mchan@broadcom.com>
Subject: Re: Definition and usage of NETIF_F_HW_SUM?
Date: Tue, 29 May 2007 14:58:08 -0700	[thread overview]
Message-ID: <20070529145808.3ba8e77a@freepuppy> (raw)
In-Reply-To: <20070529213618.GA9360@gondor.apana.org.au>

On Wed, 30 May 2007 07:36:18 +1000
Herbert Xu <herbert.xu@redhat.com> wrote:

> On Tue, May 29, 2007 at 01:58:13PM -0700, Stephen Hemminger wrote:
> > The flag NETIF_F_HW_SUM is being misused. The definition says that the device
> > is capable of checksumming any packet. When in fact from usage it seems to
> > imply that the device is capable of doing IPV6 as well as IPV4.
> 
> That would be a problem.
> 
> > Some devices like 8139too do "fake checksum offloading" because they always have to copy
> > the packet.
> > 
> > Some devices like via-rhine, don't really checksum but if they see CHECKSUM_PARTIAL then they
> > copy. This is bogus, they should just let higher layer do checksum/copy.
> 
> Actually this is OK because if they have to copy it then it's cheaper to
> checksum it there.  Both of these should be able to support all protocols.
> 
> > Devices like e1000, and bnx2 are broken because they assume only TCP/UDP and IPV4/IPV6. 
> > The definition of the flag says other protocols should work, but they probably send the
> > hardware into a state of confusion.
> 
> I just checked e1000 and it's correct as it does use the csum_offset
> when doing TX offload.  However, you're definitely right that bnx2
> seems to be broken.
> 
> > A few devices take a offset, starting point, and insertion point. This looks like
> > the correct model. But no upper layer protocols other than IPV4/IPV6 can do checksum
> > offload at present, so it seems moot.
> 
> I could easily whip up a patch to get GRE to use it for a start :)
> 
> > IMHO the correct solution would be to get rid if NETIF_F_HW_SUM and make a new flag
> > NETIF_F_IPV6_SUM. Devices that can checksum both could do NETIF_F_IPV4_SUM|NETI_F_IPV6_SUM.
> 
> We should definitely keep NETIF_F_HW_SUM for sane hardware such as the
> e1000.  Unfortunately we may just have to invent IPV6_SUM for the broken
> ones.
> 

The Marvell 88e8071 does IPV4 and IPV6 checksum, earlier chips could do arbitrary
checksum. Looks like when they added the TSO6 logic, they made transmit state machine
more protocol dependent.
-- 
Stephen Hemminger <shemminger@linux-foundation.org>

  reply	other threads:[~2007-05-29 22:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-29 20:58 Definition and usage of NETIF_F_HW_SUM? Stephen Hemminger
2007-05-29 21:36 ` Herbert Xu
2007-05-29 21:58   ` Stephen Hemminger [this message]
2007-05-30  0:10   ` Michael Chan
2007-05-29 23:45     ` Stephen Hemminger
2007-06-04 15:35       ` Ron Mercer
2007-05-30 15:53   ` [RFC] IPV6 checksum offloading in network devices Stephen Hemminger
2007-05-30 16:13     ` Patrick McHardy
2007-05-30 21:00       ` Stephen Hemminger
2007-06-27  7:44         ` David Miller

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=20070529145808.3ba8e77a@freepuppy \
    --to=shemminger@linux-foundation.org \
    --cc=herbert.xu@redhat.com \
    --cc=mchan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.