From: "Ravinandan Arakali" <[EMAIL PROTECTED]>
Date: Wed, 26 Jul 2006 12:34:28 -0700
> "You CANNOT use NETIF_F_HW_CSUM, when your hardware does not provide the
> checksum value. You must use NETIF_F_IP_CSUM. Your use of
> NETIF_F_HW_CSUM + CHECKSUM_UNNECESSARY is flat out incorrect."
NETIF_F_HW_CSUM means, on transmit, that you can handle being given a
skb with ip_summed set to CHECKSUM_HW.
When you see CHECKSUM_HW on transmit, this means that skb->csum holds
the offset into the packet where you should place the computed
checksum. Actually you are given two packet offsets, defined as
follows:
csum_start_off = (u32) (skb->h.raw - skb->data);
csum_stuff_off = (u32) ((skb->h.raw + skb->csum) - skb->data);
The first value is where you should start calculating the two's
complement checksum, and the second value is the offset into the
packet where you should place the 16-bit checksum after you have
folded it.
The thing I think you are misunderstanding is that in order to support
NETIF_F_HW_CSUM you must be able to compute the two's complement over
_ARBITRARY_ portions of the packet and be able to place the 16-bit
checkum you compute at _ARBITRARY_ locations in the packet.
Therefore, saying things like "our card can only handle IPV4 and IPV6"
have no sense when discussing CHECKSUM_HW. The algorithm of
CHECKSUM_HW on transmit is generic, the protocol in use doesn't
matter, it does a generic two's complement checksum over some section
of the packet data. This allows to handle arbitrary protocols that
make use of two's complement checksums, not just "ipv4 and ipv6".
On receive, if you want to set CHECKSUM_HW, the card must compute the
two's complement checksum over the entire packet data and place it
in skb->csum.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
