-Original Message-
From: James Bulpin [mailto:james.bul...@eu.citrix.com]
Sent: Wednesday, February 29, 2012 5:34 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] igb hard-coded mac_table[0] in igb_probe
We've noticed that the igb_probe() function hard-codes mac_table index 0
when setting the PF MAC entry. Unfortunately this happens after
igb_set_sriov_capability() has run and used mac_table[0] for the VF0
initial MAC and therefore the PF MAC silently obliterates the VF0 config.
In practice this isn't a problem because the VF0 MAC will get re-added to
the table later on igb_vf_reset_msg() etc.
The only reason this caused a problem for us was because we were using the
number of free mac_table entries as a guide to how many additional MAC
filters we could define - to work around this we simply have to allow for
a spare entry for VF0 when it eventually gets used.
This is to support backwards compatibility with legacy drivers that don't use
or support SR-IOV. The igb driver is used on several devices that don't have
SR-IOV features.
However I can see how it's a bit confusing. In our 10Gig drivers we have ended
up allocating the VF MAC addresses starting from the top of the MAC address
filter table. It would be a good idea to do this for the igb driver also to
avoid this sort of confusion and to make behavior consistent among our drivers.
I'm not sure when the resources for this work would be available though.
- Greg
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel#174; Ethernet, visit
http://communities.intel.com/community/wired