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]
Message-ID: <CAMt9YRqCH8Ab5vefMoQj39gJ8b-gsg2w5nJanW1srqt13bUkSQ@mail.gmail.com>
Date:	Wed, 4 May 2016 09:06:19 -0700
From:	Alex Duyck <aduyck@...antis.com>
To:	Or Gerlitz <ogerlitz@...lanox.com>
Cc:	Alexander Duyck <alexander.duyck@...il.com>,
	Tom Herbert <tom@...bertland.com>,
	Or Gerlitz <gerlitz.or@...il.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 Wed, May 4, 2016 at 8:50 AM, Or Gerlitz <ogerlitz@...lanox.com> wrote:
> 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?

I think the piece you are missing is GSO_PARTIAL.  Basically
GSO_PARTIAL indicates that we can perform GSO as long as all segments
are the same size and also allows for ignoring one level of headers.
So in the case of ixgbe for instance we can support tunnel offloads as
long as we allow for the inner IPv4 ID to be a fixed value which is
identified by enabling TSO_MANGLEID.  In the case of i40e, mlx4, and
mlx5 the key bit is that we just have to have the frames the same size
for all segments and then we can support tunnels with outer checksum
because the checksum has been computed once and can be applied to all
of the segmented frames.

Hope that helps.

- Alex

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ