On the issue of performance hits (specifically in regards to network
bandwidth) while running on top of hypervisor, here are some results that
I got from network heresey blog
http://networkheresy.com/category/network-virtualization/
Throughput Recv side cpu Send side cpu
Linux Bridge: 9.3 Gbps 85% 75%
OVS Bridge: 9.4 Gbps 82% 70%
OVS-STT: 9.5 Gbps 70% 70%
OVS-GRE: 2.3 Gbps 75% 97%
Protocols that can leverage the NIC TCP LSO/RSO and other such features
can achieve near line rate.
I have a series of experiments that I plan to run in the coming weeks and
will have a better idea and can post the results.
--
Vinay Bannai
408-967-7784
Cloud Engineering
On 4/22/13 12:36 AM, "Reith, Lothar" <[email protected]> wrote:
>Hi Qin,
>
>I had read that a bare metal server is being used by people who do want
>to eliminate the overhead introduced by the hypervisor to the performance
>of the server. If the server runs only a single application - why
>introduce the overhead of a hypervisor and suffer from the associated
>performance degradation?
>
>Therefore I tend to disagree with the statement, that a bare metal server
>is some kind of hypervisor.
>
>Lothar
>
>-----Ursprüngliche Nachricht-----
>Von: Qin Wu [mailto:[email protected]]
>Gesendet: Montag, 22. April 2013 03:59
>An: Reith, Lothar; Thomas Narten; Pat Thaler
>Cc: [email protected]
>Betreff: RE: [nvo3] vNICs and pNics in draft-wu-nvo3-nve2nve-04.txt
>
>Hi, Lothar:
>Bare metal server is some kind of hypervisor. As I discussed with Larry
>on the list before, usually hypervisor hosts multiple VMs. Each VM can be
>a tenant system. So I think the case B doesn't stand.
>
>Regarding Case A and Case C, I think tenant system can be either physical
>system or virtual system, as tenant system definition pointed out.
>1.If tenant system is physical system, this could be out of scope of NVO3
>since as Thomas mentioned, native connection to DC network is not
>necessary to be in the scope of NOV3. I agree with this, since if tenant
>system is physical system(e.g., physical network service appliance, the
>tenant system doesn't need to be a VM)
>
>2. If tenant system is virtual system, it has two categories:
>Category (a) Tenant system plays host role
>Category (b) Tenant system plays forwarding element role (I think it
>should be virtual forwarding element, if the tenant system is a firewall,
>it should be virtual firewall)
>
>Case A and Case C, in my understanding fall into these two categories.
>
>Regards!
>-Qin
>-----Original Message-----
>From: Reith, Lothar [mailto:[email protected]]
>Sent: Sunday, April 21, 2013 7:21 PM
>To: Thomas Narten; Pat Thaler
>Cc: [email protected]; Qin Wu
>Subject: AW: [nvo3] vNICs and pNics in draft-wu-nvo3-nve2nve-04.txt
>
>Thomas,
>
>See below. I do not agree to the wording.
>
> And I suggest to change the definition of tenant system, which I
>identified as being perhaps a root cause of confusion.
>
>Lothar
>
>-----Ursprüngliche Nachricht-----
>Von: [email protected] [mailto:[email protected]] Im Auftrag von
>Thomas Narten
>Gesendet: Freitag, 19. April 2013 20:49
>An: Pat Thaler
>Cc: [email protected]; Qin Wu
>Betreff: Re: [nvo3] vNICs and pNics in draft-wu-nvo3-nve2nve-04.txt
>
>"Pat Thaler" <[email protected]> writes:
>
>> In addition to Thomas's point, we should not restrict the number of
>> physical NICs that a tenant system can have. Some tenant systems
>> will have more than one physical NIC.
>
>Agreed.
>
>Lothar: Disagree - Given the current definition of tenant system, one
>would have to make a case differentiation throughout the document as
>follows:
>
>Case A: Tenant System is a VM
>- In this case - which may be the most important one to many - above
>statement is wrong, because then the tenant system has zero physical NICs.
>
>Case B: Tenant System is a bare metal server
>- In this case above statement is true
>
>Case C: Tenant System is "according to current definition" a router or
>firewall...
>- in this case we start referring to router ports as NICs or pNICs, which
>may further increase confusion.
>
>> We may describe some typical tenant systems as part of examining use
>> cases, but NVO3 should define behavior in terms of the network
>> interface, i.e. TSI, behavior and should not restrict tenant system
>> architecture.
>
>Another way of looking at it is that the TSI is an attachement
>point/interface to the TS. The point where the TSI attaches to the TS
>has two sides. On the tenant facing side, it appears to be a NIC. It
>looks like a NIC, behaves like a NIC, etc. On the side facing away
>from the tenant (e.g., the hypervisor in the case of a virtualized
>system) we call it a TSI. The TSI side will have attributes that are
>specific to NVO3.
>
>Does that make sense?
>
>Thomas
>
>_______________________________________________
>nvo3 mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/nvo3
>_______________________________________________
>nvo3 mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
