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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 23 Jan 2015 10:25:26 -0800
From:	Tom Herbert <therbert@...gle.com>
To:	Jesse Gross <jesse@...ira.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 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.

TCP/IP 10Gbps with 1500 byte MTU, 14 bytes for Ethernet header, 15
bytes for preamble, FCS, IPG, and no TCP options gives 9.54Gbps
maximum throughput. About what you see in STT minus overhead in first
segment.

TCP/IPv4 on VXLAN with TCP options gives max throughout 9.09Gbps,
TCP/IPv6 over VXLAN then gives 8.96Gbps. Pretty much what we see give
or take a few bytes for TCP options and rounding error.

Tom
--
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