[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54CBB54C.2050307@hp.com>
Date: Fri, 30 Jan 2015 08:46:04 -0800
From: Rick Jones <rick.jones2@...com>
To: Pravin Shelar <pshelar@...ira.com>,
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 01/29/2015 08:04 PM, Pravin Shelar wrote:
> On Thu, Jan 29, 2015 at 7:46 PM, Alexander Duyck
>> 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.
Not to pile-on or anything but indeed, there is much more to "TCP
workloads" than just bulk transfer (TCP_STREAM), which is precisely why
netperf was created oh so many years ago with its TCP_RR test to try to
replace ttcp, and why there are the methods of mine and others to do
aggregate PPS with it and other benchmarks.
Of course that comment applies not only to STT but also to any other
"get to link-rate" on a (single|smallnumberof) stream" change.
rick
--
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