> -----Original Message----- > From: Jesse Gross [mailto:je...@nicira.com] > Sent: Friday, May 02, 2014 11:33 PM > To: Suresh Kumar Reddy Reddygari > Cc: dev@openvswitch.org > Subject: Re: [ovs-dev] MacVTap support in OVS > > On Fri, May 2, 2014 at 3:04 AM, Suresh Kumar Reddy Reddygari > <suresh.re...@emulex.com> wrote: > > > > > >> -----Original Message----- > >> From: Jesse Gross [mailto:je...@nicira.com] > >> Sent: Thursday, May 01, 2014 10:07 PM > >> To: Suresh Kumar Reddy Reddygari > >> Cc: dev@openvswitch.org > >> Subject: Re: [ovs-dev] MacVTap support in OVS > >> > >> On Thu, May 1, 2014 at 2:00 AM, Suresh Kumar Reddy Reddygari > >> <suresh.re...@emulex.com> wrote: > >> > Hi, > >> > > >> > Is MacVTap support there in OVS. If not, is there any plan to support it. > >> > >> No. > >> > >> What are you trying to do? > > > > Hi Jesse, > > > > As you know, Hypervisors like Xen/Citrix/KVM typically host one or > > more virtual machines (VMs) and provide network connectivity to the VMs > by connecting to the uplink Ethernet interface via a bridge module such as > Linux Bridge or Open vSwitch (OVS.) The Hypervisors (citrix) configure the > uplink interface in MAC and VLAN promiscuous mode. But the MacVTap > driver does not configure the up-link Ethernet interface in promiscuous > mode. Instead, it programs the up-link Ethernet interface with the MAC > addresses and VLANs used by the virtual NICs in the VMs. > > Please correct me if I am wrong. > > > > There are some advantages by using MacVTap. Hence I am looking for > MacVTap support in OVS. > > > > Why are we not supporting MacVTap in OVS ? Are there any disadvantages > ? > > macvtap is a parallel mechanism for connecting VMs. It does not make sense > to "support" it in OVS. > > It is theoretically possible to have OVS configure MAC and VLAN filters in the > NIC. However, in most cases the upstream switch will flood relatively few > unknown packets so the advantages are minimal.
Hi Jesse, Thank you very much for your response. Many NIC vendors including Emulex implement mechanisms to partition a physical NIC port into channels/partitions that are presented to OS as independent physical NIC functions. The ingress packets are demuxed to one of the partition based on the destination MAC address or VLAN ID. If a virtual switch configures the uplink interface in promiscuous mode and not program MAC addresses in the NIC, then the NIC has no way to demux the packet based on destination MAC address or VLAN ID and the packets will be *replicated* across all partitions associated with the port resulting in wasted CPU cycles and PCI bandwidth. MacVTap solves this problem by configuring the MAC address of the emulated NICs in the uplink interface. We are also exploring another solution in our NIC driver by learning the MAC addresses in the transmit path and configuring the learned MAC address in NIC. Since each NIC vendor implementing a multi-channel solution will need to implement this in their driver, we thought a solution in OVS will be more elegant. Please let us know your thoughts. Thanks, Suresh. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
