netdev - Re: [PATCH net-next 0/3] openvswitch: Add STT support.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 23 Jan 2015 12:20:07 -0800
From:	Jesse Gross <jesse@...ira.com>
To:	Tom Herbert <therbert@...gle.com>
Cc:	Pravin B Shelar <pshelar@...ira.com>,
	David Miller <davem@...emloft.net>,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 0/3] openvswitch: Add STT support.

On Fri, Jan 23, 2015 at 10:25 AM, Tom Herbert <therbert@...gle.com> wrote:
> On Fri, Jan 23, 2015 at 9:38 AM, Jesse Gross <jesse@...ira.com> wrote:
>> On Fri, Jan 23, 2015 at 8:58 AM, Tom Herbert <therbert@...gle.com> wrote:
>>> On Tue, Jan 20, 2015 at 12:25 PM, Pravin B Shelar <pshelar@...ira.com> wrote:
>>>> Following patch series adds support for Stateless Transport
>>>> Tunneling protocol.
>>>> STT uses TCP segmentation offload available in most of NIC. On
>>>> packet xmit STT driver appends STT header along with TCP header
>>>> to the packet. For GSO packet GSO parameters are set according
>>>> to tunnel configuration and packet is handed over to networking
>>>> stack. This allows use of segmentation offload available in NICs
>>>>
>>>> Netperf unidirectional test gives ~9.4 Gbits/s performance on 10Gbit
>>>> NIC with 1500 byte MTU with two TCP streams.
>>>>
>>> The reason you're able to get 9.4 Gbit/s with an L2 encapsulation
>>> using STT is that it has less protocol overhead per packet when doing
>>> segmentation compared to VXLAN (without segmentation STT packets will
>>> have more overhead than VXLAN).
>>>
>>> A VXLAN packet with TCP/IP has headers
>>> IP|UDP|VXLAN|Ethernet|IP|TCP+options. Assuming TCP is stuffed with
>>> options, this is 20+8+8+16+20+40=112 bytes, or 7.4% MTU. Each STT
>>> segment created in GSO, other than the first, has just IP|TCP headers
>>> which is 20+20=40 bytes or 2.6% MTU. So this explains throughput
>>> differences between VXLAN and STT.
>>
>> Tom, what performance do you see with a single stream of VXLAN running
>> on net-next with default configuration? The difference in numbers
>> being posted here is greater than a few percent caused by protocol
>> overheard.
>
> Please look at the data I posted with the VXLAN RCO patches.

The data you posted uses 200 streams, so I assume that you are using
multiple CPUs. It's not surprising that you would be able to consume a
10G link in that case. STT can do this with a single stream and less
than 1 core (or alternately handle higher throughput). Claiming that
since both can hit 10G they are same is not accurate.

Discussing performance like this seems a little silly given that the
code is available. Pravin posted some numbers that he got, if you want
to dispute them then why don't you just try running it?
--
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