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
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
