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 PHC | |
Open Source and information security mailing list archives
| ||
|
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
Powered by blists - more mailing lists