Steve, Thanks for the response. Pls see my comments below. > -----Original Message----- > From: Stephen Hemminger [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 26, 2006 12:16 PM > To: [EMAIL PROTECTED] > Cc: netdev@vger.kernel.org; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; Leonid. Grossman > (E-mail) > Subject: Re: H/W requirements for NETIF_F_HW_CSUM > > > On Wed, 26 Jul 2006 10:28:00 -0700 > "Ravinandan Arakali" <[EMAIL PROTECTED]> wrote: > > > Hello, > > Our current NIC does not provide the actual checksum value > on receive path. > > Hence we only claim NETIF_F_IP_CSUM instead of the more general > > NETIF_F_HW_CSUM. > > > > To support this in a future adapter, we would like to know > what exactly are > > the requirements (on both Rx and Tx )to claim NETIF_F_HW_CSUM ? > > If you set NETIF_F_HW_CSUM, on transmit the adapter if > ip_summed is set > will be handed an unchecksummed frame with the offset to > stuff the checksum at. > Only difference between NETIF_F_HW_CSUM and NETIF_F_IP_CSUM > is that IP_CSUM > means the device can handle IPV4 only.
Since our adapter does IPv4 and IPv6 checksum, do we then satisfy the requirements to claim NETIF_F_HW_CSUM on Tx side ? Also, for non-TSO, we can stuff the checksum at specified offset in skb. What about TSO frames ? > > NETIF_F_HW_CSUM has no impact on receive. The form of receive > checksumming format > is up to the device. It can either put one's complement in > skb->csum and > set ip_summed to CHECKSUM_HW or if device only reports > checksum good then > set CHECKSUM_UNNECESSARY. The reason for thinking that NETIF_F_HW_CSUM and CHECKSUM_UNNECESSARY don't go together was a comment from Jeff way back in '04 when our driver was initially submitted. Quoting from that mail: "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." > > Several are a couple of subtleties to the receive processing: > * Meaning of ip_summed changes from tx to rx path and that > has to be handled > in code that does forwarding like bridges. > * If device only reports checksum okay vs bad. The packets > marked bad might > be another protocol, so should be passed up with > CHECKSUM_NONE and let any > checksum errors get detected in software. > * Checksum HW on receive should work better since then IPV6 > and nested protocols like > VLAN's can be handled. > > > Following are some specific questions: > > 1. On Tx, our adapter supports checksumming of TCP/UDP over > IPv4 and IPv6. > > This computation is TCP/UDP specific. Does the checksum > calculation need to > > be more generic ? Also, skbuff.h says that the checksum > needs to be placed > > at a specific location(skb->h.raw+skb->csum). I guess this > means the adapter > > needs to pass back the checksum to host driver after > transmission. What > > happens in case of TSO ? > > 2. On Rx, is it suffficient if we place the L4 checksum in > skb->csum ? What > > about L3 checksum ? > > > > The L3 checksum (IP) is always computed. Since the header is > in CPU cache anyway > it is faster that way. - 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
