[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1339596605.22704.363.camel@edumazet-glaptop>
Date: Wed, 13 Jun 2012 16:10:05 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: eilong@...adcom.com
Cc: David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
Tom Herbert <therbert@...gle.com>,
Robert Evans <evansr@...gle.com>,
Willem de Bruijn <willemb@...gle.com>,
Yaniv Rosner <yanivr@...adcom.com>,
Merav Sicron <meravs@...adcom.com>,
Yuval Mintz <yuvalmin@...adcom.com>
Subject: Re: [PATCH] bnx2x: fix checksum validation
On Wed, 2012-06-13 at 16:42 +0300, Eilon Greenstein wrote:
> So what you are saying is that the indication that the checksum is valid
> is interpreted as the encapsulated checksum and not just the IP
> header... This was not the intention of this code, it was meant to
> indicate that the IP header is valid.
>
IP header is always checked by our stack.
Its so fast that there is no point spending a bit in skb, and testing
this bit.
Yes, CHECKSUM_UNNECESSARY really means everything was checked up to L4
> I must admit that the code looks much better with this change. The only
> down side is that there is no longer IP checksum offload for pure IP
> packets, but that's negligible. The only thing that bothers me is that
> there is no way to indicate anything about the encapsulated packet
> separately from the outer header. Is that the way we want to keep it?
Some NIC allow for csum L3 offloading, providing the 16bit csum.
We then can :
skb->csum = csum;
skb->ip_summed = CHECKSUM_COMPLETE;
Check drivers/net/ethernet/ibm/ehea/ehea_main.c,
drivers/net/ethernet/marvell/skge.c ,
drivers/net/ethernet/marvell/sky2.c , ... for examples.
When a layer is removed(pulled), we can use skb_postpull_rcsum() and
friends (check net/ipv4/ip_gre.c for example) to keep skb->csum up2date.
If bnx2x provides this csum (for non TCP/UCP packets or fragments), you
could fallback to this CHECKSUM_COMPLETE stuff.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists