Re: Are "skb->data" physically continuous?

[Nick Patavalis (npat@inaccessnetworks.com)]

On Sun, Sep 14, 2003 at 12:43:33PM +0300, Shmulik Hen wrote:
> 
> You may want to take a look at e100_main.c in one of the latest 2.4.x 
> kernels. There you should be able to see how to deal with 
> dev->features and the flags NETIF_F_SG for scatter-gather 
> capabilities and NETIF_F_*_CSUM for checksum offloading capabilities.

I'm trying to make sense of the checksum-offloading mechanisms, and
how they should be used by a driver. By reading the source of
"e100_prepare_xmit_buff()", what I can figure out is:

  - the driver declares the NETIF_F_HW_CSUM capability
  - the kernel sends skbs in which "skb->ip_summed" is CHECKSUM_HW,
    and where all the checksum-values are *not* calculated. It is the
    responsibility of the driver / hardware to calculate them.
  - the driver calculates the pseudo-header checksums for TCP and 
    UDP packets, and the hardware takes care of re-calculating them 
    to also cover the data.

What about the IP-header checksum? Is it calculated by the kernel, or
by the hardware?

My confusion is worse regarding the receiver-path. 

What should the driver / hardware fill-in as checksum values for IP /
TCP / UDP checksums? Will it fill-in pseudo-header ckecksums so that
the kernel can easily veryfy them, or complete payload-also checksums?
In the e100 case, does the hardware fill-in these pseude-checksums by
itself (or does the driver do it)? 

How should the kernel be notified if the calculation of a checksum
failed (checksum does not match). Reading the e100 source, I see that
if the checksums (any of the checksums, I presume) of a packet are
invalid, then the driver sets "skb->ip_summed" to CHECKSUM_NONE; but
won't this force the kernel to re-calculate the checksums, although
they are, in this case, a-priori known to be invalid?

Thanks in advance
/npat

-- 
Mathematics belongs to God.
  -- Donald E. Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html