From: Abraham vd Merwe <abraham@2d3d.co.za>
To: "Richard B. Johnson" <root@chaos.analogic.com>
Cc: Linux Kernel Development <linux-kernel@vger.kernel.org>
Subject: Re: CHECKSUM_HW not behaving as expected
Date: Thu, 11 Apr 2002 17:37:14 +0200 [thread overview]
Message-ID: <20020411173714.A3869@crystal.2d3d.co.za> (raw)
In-Reply-To: <20020411170458.A2786@crystal.2d3d.co.za> <Pine.LNX.3.95.1020411111450.14550A-100000@chaos.analogic.com>
[-- Attachment #1: Type: text/plain, Size: 2617 bytes --]
Hi Richard!
> > In Rubini's "Linux Device Drivers 2nd edition" he states in his networking
> > chapter that skb->ip_summed = CHECKSUM_HW means that the hardware already
> > performed a checksum and that the upper layers therefore don't need to do it
> > (He also states that CHECKSUM_NONE (default) means that it still needs to be
> > verified).
> >
> > I'm currently writing a network driver for 2.4.17 and the chip automatically
> > performs checksums and you can tell it to exclude the CRC from the packet or
> > not before making it available for the host. Now, if I configure it to
> > exclude the CRC and use skb->ip_summed = CHECKSUM_HW I get:
> >
>
> CRC not!
> The IP checksum is not the CRC. Some new network boards "know" about
> the IP checksum and can compute it. The CRC is a hardware-computed CRC
> that is appended to every Ethernet packet. The CRC must be received
> intact or the packet is rejected (dropped). If it's possible to 'tell'
> your board to exclude the CRC, this is not what you want.
No, you misunderstood. The card still verify the CRC. You can just instruct
it not to include it in the frame that you want to copy, e.g. say you
receive a 64-byte ethernet frame, then it can either tell you "copy from my
buffer 64 bytes" or if you're not interested in the CRC, "copy 60 bytes from
my buffer"
What I don't want is for the kernel to verify the CRC again since it's
already been done by the hardware (and I save 4 bytes on the copy (: )
> If you already know this, then the possible problem is that the
> packet length is wrong. The IP checksum is a 16-bit integer of
> 16-bit integers. This means that the packet length must be an even
> number. Your driver may be returning the wrong length. Also, when
> you transmit, if the hardware is going to do the checksum, what
> does it expect at the checksum offset in the IP packet? Hardware
> checksums usually don't 'skip' some offset so the checksum value
> should probably be 0 when it goes to your hardware.
Dope. Somehow I thought it was the "ethernet frame checksum" - not quite the
same thing :P
--
Regards
Abraham
You will pioneer the first Martian colony.
__________________________________________________________
Abraham vd Merwe - 2d3D, Inc.
Device Driver Development, Outsourcing, Embedded Systems
Cell: +27 82 565 4451 Snailmail:
Tel: +27 21 761 7549 Block C, Aintree Park
Fax: +27 21 761 7648 Doncaster Road
Email: abraham@2d3d.co.za Kenilworth, 7700
Http: http://www.2d3d.com South Africa
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
prev parent reply other threads:[~2002-04-11 15:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-11 15:04 Abraham vd Merwe
2002-04-11 15:01 ` David S. Miller
2002-04-11 15:31 ` Richard B. Johnson
2002-04-11 15:28 ` David S. Miller
2002-04-11 15:39 ` Richard B. Johnson
2002-04-11 15:37 ` Abraham vd Merwe [this message]
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=20020411173714.A3869@crystal.2d3d.co.za \
--to=abraham@2d3d.co.za \
--cc=linux-kernel@vger.kernel.org \
--cc=root@chaos.analogic.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
all inboxes | Powered by JetHome®