On Thu, May 8, 2014 at 1:54 AM, Suresh Kumar Reddy Reddygari <suresh.re...@emulex.com> wrote: > > >> -----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.
Are you also trying to enforce bandwidth or other resource limits across the partitions? Otherwise, this makes little sense when you already have a switch. If you really want, you could probably use macvlan (not macvtap) to create interfaces that are attached to OVS normally. However, this would not be automatic or particularly integrated. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
