> > > 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. > >>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 > 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? > >>Vic: I made the traffic as a L3 traffic. > > Regards, Marc > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
