Hi Chen,
I have tried to answer your questions as best I can below. However I am
not the maintainer for the ixgbe SR-IOV functionality. It is Greg Rose
who is the maintainer so I have added him and the e1000-devel mailing
list to this email.
Thanks,
Alex
On 12/19/2012 07:08 AM, Rugang Chen wrote:
> Hi Alexander Duyck,
>
>
>
> We are building a Virtualization test bed with Intel 82599 NIC on Linux
> Host and KVM is used. Following is a brief description:
>
>
>
> *Host system:* Ubuntu 12.04 LTS (GNU/Linux 3.2.0-23-generic x86_64)
>
> *NIC: *Intel 82599EB, ixgbe driver version is 3.11.33. See more details
> in attachment "lspci.log"
>
> *KVM: *QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008
> Fabrice Bellard (run "kvm --version")**
>
> *Virtual Machines:*
>
> · Two Virtual Machines are installed with a same Linux
> kernel(2.6.26.5), and version of ixgbevf driver running on Virtual
> Machines is 2.6.2
>
> · There's a VF (Virtual Function) used as NIC in each Virtual
> Machine, and the two VFs are of the same PF(Physical Function)
>
> *Configuration:*
>
> · Both PF (Intel 8259 NIC) and VF(ixgbevf NIC seen in Virtual
> Machine) are set to "promisc on multicast on allmulticast on" with tool
> "iproute2"
>
> · Load "ixgbe.ko" in Host with parameter "max_vfs=16"
>
> *Result: *
>
> · When sending multicast packets out from one Virtual Machine A,
> no packet is seen in another Virtual Machine B**
>
> In our testing, multicast MAC address in packets is “01:00:5e:00:00:d2”
>
> · On Virtual Machine, when we run "ip maddr add
> 01:00:5e:00:00:d2 dev ethx"(ethx = interface name seen in Virtual
> Machine), we can debug that "ixgbe_update_mc_addr_list_vf" is called **
>
> · Communication of unicast from A to B is OK**
>
>
>
> We checked the ixgbe driver codes(version 3.11.33), and seen following:
> (Function “*ixgbe_set_rx_mode*”, file “*ixgbe_main.c*”)
>
>
>
> if (hw->mac.type !=ixgbe_mac_82598EB) {
>
> vmolr |= IXGBE_READ_REG(hw, IXGBE_VMOLR(VMDQ_P(0))) &
>
> ~(IXGBE_VMOLR_MPE|IXGBE_VMOLR_ROMPE|
>
> IXGBE_VMOLR_ROPE);
>
> IXGBE_WRITE_REG(hw, IXGBE_VMOLR(VMDQ_P(0)), vmolr);
>
> }
>
>
>
> We can see that“IXGBE_VMOLR_MPE” and“IXGBE_VMOLR_ROMPE” are disabled,
> and this may explain why multicast doesn’t work.
>
> Checking the previous version of file "ixgbe_main.c" shipped in kernel
> source, we found that “IXGBE_VMOLR_MPE” and“IXGBE_VMOLR_ROMPE” are
> disabled since the driver was firstly in the kernel.
>
> So our question are:
>
> · Why we disable “IXGBE_VMOLR_MPE” and“IXGBE_VMOLR_ROMPE”, and
> only enable them for 82598EB in latest 3.11.33?
The code you are referencing above only affects the PF specifically.
The VMDQ_P(0) macro is accessing the offloads register for the PF itself.
The VMOLR_MPE bit would be undesirable as that enables receive of all
multicast packets. As far as the VMOLR_ROMPE bit it should be enabled
the first time a VF has a reset event. I believe you should see this in
ixgbe_sriov.c if you grep for VMOLR_ROMPE in the driver.
The 82598EB does not have a VMOLR register and does not support SR-IOV.
This is why it is excluded in the code you reference above.
>
> · Multicast from VF to VF (or between VF and PF) is supported ?
Yes it is my understanding that this is supported.
> · If we just enable “IXGBE_VMOLR_MPE” and“IXGBE_VMOLR_ROMPE” for
> multicast on 82599EB, will there be any other influence ?
The problem with enabling these by default is that it would mean that
the PF would always be receiving multicast traffic even for groups that
it did not add.
>
> Thanks for your patience to read the mail. Wait for your answer which
> may be very helpful to us.
>
>
>
> Best regards,
>
> Rugang Chen
>
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit
http://communities.intel.com/community/wired
