netdev - Re: [PATCH net-next v2 0/6] net: 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:	Thu, 29 Jan 2015 20:04:34 -0800
From:	Pravin Shelar <pshelar@...ira.com>
To:	Alexander Duyck <alexander.duyck@...il.com>
Cc:	David Miller <davem@...emloft.net>, netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v2 0/6] net: Add STT support.

On Thu, Jan 29, 2015 at 7:46 PM, Alexander Duyck
<alexander.duyck@...il.com> wrote:
> On 01/29/2015 03:29 PM, Pravin B Shelar 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
>>
>> The protocol is documented at
>> http://www.ietf.org/archive/id/draft-davie-stt-06.txt
>>
>> I will send out OVS userspace patch on ovs-dev mailing list.
>>
>> Following are test results. All tests are done on net-next with
>> STT and VXLAN kernel device without OVS.
>>
>> Single Netperf session:
>> =======================
>> VXLAN:
>>     CPU utilization
>>      - Send local: 1.26
>>      - Recv remote: 8.62
>>     Throughput: 4.9 Gbit/sec
>> STT:
>>     CPU utilization
>>      - Send local: 1.01
>>      - Recv remote: 1.8
>>     Throughput: 9.45 Gbit/sec
>>
>> Five Netperf sessions:
>> ======================
>> VXLAN:
>>     CPU utilization
>>      - Send local: 9.7
>>      - Recv remote: 70 (varies from 60 to 80)
>>     Throughput: 9.05 Gbit/sec
>> STT:
>>     CPU utilization
>>      - Send local: 5.85
>>      - Recv remote: 14
>>     Throughput: 9.47 Gbit/sec
>>
>
> What does the small packet or non-TCP performance look like for STT vs
> VXLAN?  My concern is that STT looks like it is a one trick pony since
> all your numbers show is TCP TSO performance, and based on some of the
> comments in your patches it seems like other protocols such as UDP are
> going to suffer pretty badly due to things like the linearization overhead.
>

Current implementation is targeted for TCP workloads thats why I
posted numbers with TCP, once UDP is optimized we can discuss UDP
numbers. I am pretty sure the STT code can be optimized further
specially for protocols other than TCP.
--
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