Not to mention that LOM is likely an additional 8-12 months from the
chipsets hitting the market.
On 8/29/12 5:25 PM, Jon Hudson wrote:
Totally agreed, but that will require all new hardware.
One of the gains of STT was the use of current off the self
performance capabilities.
On Wed, Aug 29, 2012 at 5:19 PM, Somesh Gupta <[email protected]
<mailto:[email protected]>> wrote:
I assume that majority of the NIC vendors will support the
stateless offloads for
VxLAN and NvGRE by sometime next year -- so they should all be on
equal footing
from that point of view.
the additional overhead of encap/decap compared to the overhead of
copying date between
the VM and the hypervisor should be minimal.
*From:*[email protected] <mailto:[email protected]>
[mailto:[email protected] <mailto:[email protected]>] *On
Behalf Of *smith, erik
*Sent:* Wednesday, August 29, 2012 3:48 PM
*To:* David LE GOFF; [email protected] <mailto:[email protected]>
*Subject:* Re: [nvo3] performance limitations with virtual switch
as the nvo3 end point
Hi David, a few months ago we did some basic performance testing
with OVS and were pretty happy with the results. For one reason
or another we were under the impression that using OVS to
encap/decap would limit our total throughput to 4-6 Gbps and this
turned out to not be the case. In our configuration, we were able
to demonstrate 20 Gbps over a bonded pair of 10GbE NICs using STT
for the overlay. Our testing wasn't exactly scientific but I also
found an interesting blog post by Martin Cassado that our limited
testing seems to corroborate.
I haven't done any testing with VMware and VXLAN. However, if
you're experiencing limited performance with OVS on <insert your
favorite Linux distro here>, I would suggest playing around with
Jumbo frames (starting from within the guest) and working your way
out to the physical interfaces.
For additional information, refer to the following:
1)Martin Cassado's blog: (
http://networkheresy.com/2012/06/08/the-overhead-of-software-tunneling/
)
2)I posted something to my blog a bit less detailed (but with
diagrams) earlier this week (
http://brasstacksblog.typepad.com/brass-tacks/2012/08/network-virtualization-networkings-21st-century-equivalent-to-the-space-race.html
) Specifically, the final three diagrams..
Erik
*From:*[email protected] <mailto:[email protected]>
[mailto:[email protected] <mailto:[email protected]>] *On
Behalf Of *David LE GOFF
*Sent:* Wednesday, August 29, 2012 9:16 AM
*To:* [email protected] <mailto:[email protected]>
*Subject:* [nvo3] performance limitations with virtual switch as
the nvo3 end point
Hi Folks,
Did anyone experienced some performance limitations in Labs with
the virtual switch function as the bottleneck when dealing with
network overlays?
I mean with the tunnel end point located on the hypervisor
(virtual switch), setting up Tagging, QoS, ACL,
encryption/decryption, etc. require significant CPUs.
I know there is not yet official nvo3 implementation there, though
VSphere 5 announced it with VXLAN recently but at any chance if
some studies have been done, I would be glad to read those.
I know STT has been built to overcome such challenges thanks to
the NIC offload capabilities...
These studies may also drive the brainstorming about which
protocol we may use/build?
Thank you!
david le goff.
_______________________________________________
nvo3 mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/nvo3
--
"Do not lie. And do not do what you hate."
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Casado
Nicira Networks, Inc.
www.nicira.com
cell: 650-776-1457
~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
