netdev - Re: [net-next PATCH v2 5/9] mlx4: Add support for UDP tunnel segmentation with outer checksum offload

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 4 May 2016 18:50:33 +0300
From:	Or Gerlitz <ogerlitz@...lanox.com>
To:	Alexander Duyck <alexander.duyck@...il.com>,
	Tom Herbert <tom@...bertland.com>
CC:	Or Gerlitz <gerlitz.or@...il.com>,
	Alexander Duyck <aduyck@...antis.com>,
	"talal@...lanox.com" <talal@...lanox.com>,
	Linux Netdev List <netdev@...r.kernel.org>,
	Michael Chan <michael.chan@...adcom.com>,
	"David Miller" <davem@...emloft.net>,
	Gal Pressman <galp@...lanox.com>,
	"Eran Ben Elisha" <eranbe@...lanox.com>
Subject: Re: [net-next PATCH v2 5/9] mlx4: Add support for UDP tunnel
 segmentation with outer checksum offload

On 5/3/2016 6:29 PM, Alexander Duyck wrote:
> We split the one that would be a different size off via GSO.  So we
> end up sending up 2 frames to the device if there is going to be one
> piece that doesn't quite match.  We split that one piece off via GSO.
> That is one of the reasons why I referred to it as partial GSO as all
> we are using the software segmentation code for is to make sure we
> have the GSO block consists of segments that are all the same size.

I see, so if somehow it happens a lot that the TCP stack sends down 
something which once segmented ends up with the last segment being of 
different size from the other ones we would have to call the NIC xmit 
function twice (BTW can we use xmit_more here?)  -- which could be 
effecting performance, I guess.

GSO_UDP_TUNNEL_CSUM (commit  0f4f4ffa7 "net: Add GSO support for UDP 
tunnels with checksum") came to mark "that a device is capable of 
computing the UDP checksum in the encapsulating header of a UDP tunnel" 
-- and the way we use it here is that we do advertize that bit towards 
the stack for devices whose HW can **not** do that, and things work b/c 
of LCO (this is my understanding).

I miss something in the bigger picture here, what does this buy us? e.g 
vs just letting this (say) vxlan tunnel use zero checksum on the outer 
UDP packet, is that has something to do with RCO?

Or.