[dpdk-dev] vswitches performance comparison

[dpdk-dev] vswitches performance comparison

[Jun Xiao]

After CloudNetEngine vswitch technical preview is launched, we received quite
a few queries on vswitches performance comparison, but we cannot simply give a
 test result on our platform because performance varies on different H/Ws and
different workloads, and that's why we encourage you to try the evaluation 
package to get real data on your setup.

Anyway, we share a little more performance data on our H/W which is a comparison
 among native kernel OVS/OVS-DPDK/CNE vswitch under the most common workload:
concurrent bi-directional TCP traffics cross hosts, and hope you can have a rough idea.
http://www.cloudnetengine.com/weblog/2015/07/22/vswitches-performance-comparison/

Thanks,
Jun

Re: [dpdk-dev] [ovs-discuss] vswitches performance comparison

[Gray, Mark D]

> -----Original Message-----
> From: discuss [mailto:discuss-bounces@openvswitch.org] On Behalf Of Jun
> Xiao
> Sent: Tuesday, July 21, 2015 7:01 PM
> To: discuss; dev
> Subject: [ovs-discuss] vswitches performance comparison
> 
> After CloudNetEngine vswitch technical preview is launched, we received
> quite a few queries on vswitches performance comparison, but we cannot
> simply give a  test result on our platform because performance varies on
> different H/Ws and different workloads, and that's why we encourage you to
> try the evaluation package to get real data on your setup.
> 
> Anyway, we share a little more performance data on our H/W which is a
> comparison  among native kernel OVS/OVS-DPDK/CNE vswitch under the
> most common workload:
> concurrent bi-directional TCP traffics cross hosts, and hope you can have a
> rough idea.
> http://www.cloudnetengine.com/weblog/2015/07/22/vswitches-
> performance-comparison/

I think there is an issue with you methodology. ovs-dpdk performance should be
significantly higher than kernel ovs.

> 
> Thanks,
> Jun
> _______________________________________________
> discuss mailing list
> discuss@openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss

Re: [dpdk-dev] [ovs-discuss] vswitches performance comparison

[Jun Xiao]

I'd like to hope that's my methodology problem, but I just follow the installation guide without any customization.

Hi Mark, do you have any performance data share with us? Maybe we are using different type of workloads, like I mentioned I am using typical data center workload, I guess you are talking about NFV type of workload?

Thanks,
Jun
Sent from my iPhone

> On Jul 22, 2015, at 2:14 AM, Gray, Mark D <mark.d.gray@intel.com> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: discuss [mailto:discuss-bounces@openvswitch.org] On Behalf Of Jun
>> Xiao
>> Sent: Tuesday, July 21, 2015 7:01 PM
>> To: discuss; dev
>> Subject: [ovs-discuss] vswitches performance comparison
>> 
>> After CloudNetEngine vswitch technical preview is launched, we received
>> quite a few queries on vswitches performance comparison, but we cannot
>> simply give a  test result on our platform because performance varies on
>> different H/Ws and different workloads, and that's why we encourage you to
>> try the evaluation package to get real data on your setup.
>> 
>> Anyway, we share a little more performance data on our H/W which is a
>> comparison  among native kernel OVS/OVS-DPDK/CNE vswitch under the
>> most common workload:
>> concurrent bi-directional TCP traffics cross hosts, and hope you can have a
>> rough idea.
>> http://www.cloudnetengine.com/weblog/2015/07/22/vswitches-
>> performance-comparison/
> 
> I think there is an issue with you methodology. ovs-dpdk performance should be
> significantly higher than kernel ovs.
> 
>> 
>> Thanks,
>> Jun
>> _______________________________________________
>> discuss mailing list
>> discuss@openvswitch.org
>> http://openvswitch.org/mailman/listinfo/discuss

Re: [dpdk-dev] [ovs-discuss] vswitches performance comparison

[Gray, Mark D]

> 
> I'd like to hope that's my methodology problem, but I just follow the
> installation guide without any customization.
> 
> Hi Mark, do you have any performance data share with us? Maybe we are
> using different type of workloads, like I mentioned I am using typical data
> center workload, I guess you are talking about NFV type of workload?

The number getting floated around on the mailing list recently is 16.5Mpps
for phy-phy. However, I don't think we have any iperf data off-hand for your
usecase. When we test throughput into the vm we usually generate the traffic externally
and send NIC->OVS->VM->OVS->NIC. This is a little different to your setup.

I do know, however, that ovs-dpdk typically has a much larger throughput than
the kernel space datapath.
 
Have you seen this? https://wiki.opnfv.org/characterize_vswitch_performance_for_telco_nfv_use_cases

> 
> Thanks,
> Jun

Re: [dpdk-dev] [ovs-discuss] vswitches performance comparison

[Jun Xiao]

> On Jul 22, 2015, at 2:36 AM, Gray, Mark D <mark.d.gray@intel.com> wrote:
> 
> 
>> 
>> I'd like to hope that's my methodology problem, but I just follow the
>> installation guide without any customization.
>> 
>> Hi Mark, do you have any performance data share with us? Maybe we are
>> using different type of workloads, like I mentioned I am using typical data
>> center workload, I guess you are talking about NFV type of workload?
> 
> The number getting floated around on the mailing list recently is 16.5Mpps
> for phy-phy. However, I don't think we have any iperf data off-hand for your
> usecase. When we test throughput into the vm we usually generate the traffic externally
> and send NIC->OVS->VM->OVS->NIC. This is a little different to your setup.
> 

I guess pmd driver is used inside VM in that case, right?
> I do know, however, that ovs-dpdk typically has a much larger throughput than
> the kernel space datapath.
> 

I'd like to say it depends on workloads, for small/medium packet size workload, that's definitely true, while for TSO size workload, it's not that obvious (or worse) as data path overheads are amortized and H/W can be leveraged.
> Have you seen this? https://wiki.opnfv.org/characterize_vswitch_performance_for_telco_nfv_use_cases
> 

Thanks for the pointer, I'll try later.
>> 
>> Thanks,
>> Jun

Re: [dpdk-dev] vswitches performance comparison

[Stephen Hemminger]

On Wed, 22 Jul 2015 02:00:42 +0800
"Jun Xiao" <jun.xiao@cloudnetengine.com> wrote:

> After CloudNetEngine vswitch technical preview is launched, we received quite
> a few queries on vswitches performance comparison, but we cannot simply give a
>  test result on our platform because performance varies on different H/Ws and
> different workloads, and that's why we encourage you to try the evaluation 
> package to get real data on your setup.
> 
> Anyway, we share a little more performance data on our H/W which is a comparison
>  among native kernel OVS/OVS-DPDK/CNE vswitch under the most common workload:
> concurrent bi-directional TCP traffics cross hosts, and hope you can have a rough idea.
> http://www.cloudnetengine.com/weblog/2015/07/22/vswitches-performance-comparison/
> 
> Thanks,
> Jun

Since the real bottleneck in most vswitches is per-packet overhead.
I would recommend running RFC-2544 tests for better data.

You probably need to use something like pktgen to get enough packets-per-second.

Re: [dpdk-dev] [ovs-discuss] vswitches performance comparison

[Gray, Mark D]

> >>
> >> I'd like to hope that's my methodology problem, but I just follow the
> >> installation guide without any customization.
> >>
> >> Hi Mark, do you have any performance data share with us? Maybe we are
> >> using different type of workloads, like I mentioned I am using
> >> typical data center workload, I guess you are talking about NFV type of
> workload?
> >
> > The number getting floated around on the mailing list recently is
> > 16.5Mpps for phy-phy. However, I don't think we have any iperf data
> > off-hand for your usecase. When we test throughput into the vm we
> > usually generate the traffic externally and send NIC->OVS->VM->OVS-
> >NIC. This is a little different to your setup.
> >
> 
> I guess pmd driver is used inside VM in that case, right?

Yes, but even when we use virtio-net we see the same if not *slightly* better
performance.

> > I do know, however, that ovs-dpdk typically has a much larger
> > throughput than the kernel space datapath.
> >
> 
> I'd like to say it depends on workloads, for small/medium packet size
> workload, that's definitely true, while for TSO size workload, it's not that
> obvious (or worse) as data path overheads are amortized and H/W can be
> leveraged.

For large packets the switch will eventually saturate the NIC at line rate but the
total aggregate throughput of the switch should be faster (you could
add more interfaces for example to take advantage of that). 

TSO is missing from the DPDK ports at the moment but it is something
we plan to look at. We are currently enabling Jumbo frames (which don't
work at the moment).

> > Have you seen this?
> > https://wiki.opnfv.org/characterize_vswitch_performance_for_telco_nfv_
> > use_cases
> >
> 
> Thanks for the pointer, I'll try later.
> >>
> >> Thanks,
> >> Jun

Re: [dpdk-dev] vswitches performance comparison

[Gray, Mark D]

> "Jun Xiao" <jun.xiao@cloudnetengine.com> wrote:
> 
> > After CloudNetEngine vswitch technical preview is launched, we
> > received quite a few queries on vswitches performance comparison, but
> > we cannot simply give a  test result on our platform because
> > performance varies on different H/Ws and different workloads, and
> > that's why we encourage you to try the evaluation package to get real data
> on your setup.
> >
> > Anyway, we share a little more performance data on our H/W which is a
> > comparison  among native kernel OVS/OVS-DPDK/CNE vswitch under the
> most common workload:
> > concurrent bi-directional TCP traffics cross hosts, and hope you can have a
> rough idea.
> > http://www.cloudnetengine.com/weblog/2015/07/22/vswitches-
> performance-
> > comparison/
> >
> > Thanks,
> > Jun
> 
> Since the real bottleneck in most vswitches is per-packet overhead.
> I would recommend running RFC-2544 tests for better data.
> 
> You probably need to use something like pktgen to get enough packets-per-
> second.

Yeah this is the methodology that we use aswell.