lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20140901.214233.2138663914922963186.davem@davemloft.net>
Date:	Mon, 01 Sep 2014 21:42:33 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	therbert@...gle.com
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH net-next 0/6] net: Checksum offload changes - Part VI

From: Tom Herbert <therbert@...gle.com>
Date: Sun, 31 Aug 2014 15:12:40 -0700

> I am working on overhauling RX checksum offload. Goals of this effort
> are:
> 
> - Specify what exactly it means when driver returns CHECKSUM_UNNECESSARY
> - Preserve CHECKSUM_COMPLETE through encapsulation layers
> - Don't do skb_checksum more than once per packet
> - Unify GRO and non-GRO csum verification as much as possible
> - Unify the checksum functions (checksum_init)
> - Simplify code
> 
> What is in this seventh patch set:
> 
> - Add skb->csum. This allows a device or GRO to indicate that an
>   invalid checksum was detected.
> - Checksum unncessary to checksum complete conversions.
> 
> With these changes, I believe that the third goal of the overhaul is
> now mostly achieved. In the case of no encapsulation or one layer of
> encapsulation, there should only be at most one skb_checksum over
> each packet (between GRO and normal path). In the case of two layers
> of encapsulation, it is still possible with the right combination of
> non-zero and zero UDP checksums to have >1 skb_checksum. For instance:
> IP>GRE(with csum)>IP>UDP(zero csum)>VXLAN>IP>UDP(non-zero csum),
> would likely necessiate an skb_checksum in GRO and normal path.
> This doesn't seem like a common scenario at all so I'm inclined to
> not address this now, if multiple layers of encapsulation becomes
> popular we can reassess.
> 
> Note that checksum conversion shows a nice improvement for RX VXLAN when
> outer UDP checksum is enabled (12.65% CPU compared to 20.94%). This
> is not only from the fact that we don't need checksum calculation on
> the host, but also allows GRO for VXLAN in this case. Checksum
> conversion does not help send side (which still needs to perform
> a checksum on host). For that we will implement remote checksum offload
> in a later patch
> (http://tools.ietf.org/html/draft-herbert-remotecsumoffload-00).
> 
> Please review carefully and test if possible, mucking with basic
> checksum functions is always a little precarious :-)

Awesome work, I love watching infrastructure gradually fall into
place like this :-)

Series applied, thanks!
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ