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
> 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.
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.
> 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/.
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
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
