Subject: [nvo3] Comments of draft-liu-nvo3-ps-vxlan-perfomance-00

From: "Lizhong Jin" <[email-masked]>
Date: Tue, 8 Jul 2014 10:32:46 +0800

Hi authors,

I do not quite understand the purpose of this draft. But the performance
issues listed in section 3.1 may not true if the newly designed NIC is
applied. Some vendors are designing NIC to support VXLAN offload, and could
provide very good performance. The performance issue will not be a problem
with the emerging of newly designed NIC.

In the draft, you did not point out the tested traffic type. The large TCP
packet performance is a very important test point. You could refer to link
http://networkheresy.com/2012/06/08/the-overhead-of-software-tunneling/.

Regards

Lizhong

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 8 Jul 2014 10:21:26 -0700

Hello Vic, Lizhong et al.,

> I do not quite understand the purpose of this draft.

informal draft, providing numbers for VxLAN tunneling China Mobile has 
measured and how they have measured?  Having some real numbers seems a good 
purpose to me.

Discussing these numbers I have a few questions/comments though: I had 
several times a "why?" on my mind when seeing statements like:

   b) Memory: Memory is not sensitive from the test result. But we
      still think it should be listed as one VxLAN performance index.

So memory doesn't seem to matter really but it still should be a performance 
index? Why?

   e) Packet-lost: Virtual network may have few packet-lost because of
      unstable of vCPU. Less than 2% of packet-lost is acceptable.

Why is 2% acceptable?  For what kind of traffic?  And if the forwarding is 
not stable, what are these "2%"? Average? Maximum?

   c) Latency: When traffic is forwarded between VM to VM across two
      different physical server. Latency should be an index.

Again: why is it relevant? Assuming it is: was it measured?

   VxLAN Scalable test issues

I would have thought the relevant number for software VxLAN is roughly the 
number of VMs you have on one server, maybe with a small multiplier. Why 
trying to test several thousand VxLAN VNIs?  That seems relevant for 
dedicated hardware switches that aggregate (?).

The table with the CPU increase has some extreme numbers like 24.65% for 
server-2. I wonder how large is the error of the numbers actually? Or any 
idea where these extreme numbers come from?

> But the performance 

Probably but this is the difference between real measurement and just a 
statement (as reasonable as the statement is). I hope we will see 
measurements for NIC-offload too one day.

If today's servers cannot perform VxLAN as good as we expect then that's an 
important point - for now. Not sure how often Data centers renew their 
servers - 2 years as write-off period?  So at least for this time 
technology/designs should address the offload onto network devices if servers 
lack the performance.

> http://networkheresy.com/2012/06/08/the-overhead-of-software-tunneling/.

Honestly, sending large TCP frames through a TSO NIC gives interesting 
numbers but is also a bit artificial - of course the numbers are good, that's 
what it is purpose-build for. And what about UDP, i.e. when you need GSO or 
something? Is this still "commodity" hardware we talk about?

Regards, Marc

---

From: "Lizhong Jin" <[email-masked]>
Date: Wed, 9 Jul 2014 10:52:37 +0800

> > applied. Some vendors are designing NIC to support VXLAN offload, and
> > could provide very good performance. The performance issue will not be
> > a problem with the emerging of newly designed NIC.
> 
> technology/designs should address the offload onto network devices if
> servers lack the performance.
> >>Vic: agreed.
> To Lizhong: I think NIC may not matter most. The vNIC to the VSwitch maybe
> matters.
[Lizhong] NIC offload is will greatly improve the performance. You could
refer to one test result at link:
http://www.mellanox.com/blog/2013/09/connectx-3-pro-hardware-offload-engines
/. The traditional NIC does not have good offloading support for tunnel
packet, e.g, chechsum, TSO/LRO, Flow steering, IOV, etc.

Regards
Lizhong

> 
> 
> > In the draft, you did not point out the tested traffic type. The large
> > TCP packet performance is a very important test point. You could refer
> > to link
> >>Vic: I made the traffic as a L3 traffic.
> 
> Regards, Marc
> 
>