Re: [PATCH] net: update the usage of CHECKSUM_UNNECESSARY

On Tue, May 08, 2012 at 07:20:58PM +0100, Ben Hutchings wrote:

On Tue, 2012-05-08 at 20:48 +0300, Michael S. Tsirkin wrote:

quoted

On Mon, Mar 19, 2012 at 02:12:41PM -0700, Yi Zou wrote:

quoted

As suggested by Ben, this adds the clarification on the usage of
CHECKSUM_UNNECESSARY on the outgoing patch. Also add the usage
description of NETIF_F_FCOE_CRC and CHECKSUM_UNNECESSARY
for the kernel FCoE protocol driver.

This is a follow-up to the following:
http://patchwork.ozlabs.org/patch/147315/

Signed-off-by: Yi Zou <redacted>
Cc: Ben Hutchings <redacted>
Cc: Jeff Kirsher <redacted>
Cc: www.Open-FCoE.org <redacted>
---

 include/linux/skbuff.h |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 8dc8257..a2b9953 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h

@@ -94,6 +94,13 @@
  *			  about CHECKSUM_UNNECESSARY. 8)
  *	NETIF_F_IPV6_CSUM about as dumb as the last one but does IPv6 instead.
  *
+ *	UNNECESSARY: device will do per protocol specific csum. Protocol drivers
+ *	that do not want net to perform the checksum calculation should use
+ *	this flag in their outgoing skbs.
+ *	NETIF_F_FCOE_CRC  this indicates the device can do FCoE FC CRC
+ *			  offload. Correspondingly, the FCoE protocol driver
+ *			  stack should use CHECKSUM_UNNECESSARY.
+ *
  *	Any questions? No questions, good. 		--ANK
  */
 

So just to make sure I understand, you never get
UNNECESSARY packets on tx unless you declared NETIF_F_FCOE_CRC?

Maybe the comment says this somehow but could not figure it out.

That's what should happen now.  In future CHECKSUM_UNNECESSARY could be
used on output by other protocols which don't use TCP/IP-style
checksums, but always dependent on the output device supporting the
relevant offload feature.

Ben.

Isn't there another case: a device passes UNNECESSARY in on rx,
and the skb is forwarded to another device?
For example it is handled this way by tun, giving a nice
performance boost for VMs, see 10a8d94a95742bb15b4e617ee9884bb4381362be

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.