[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. Regards, James -- 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® Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] igb hard-coded mac_table[0] in igb_probe
> -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® Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] igb hard-coded mac_table[0] in igb_probe
Hi Greg, Thanks for the reply and explanation. It does sound like a top down allocation strategy would work. From my point of view it's not high priority so maybe something for the possible future enhancements backlog. We could easily make the code change but we don't have the test infrastructure to properly regression test it. Thanks, James > -Original Message- > From: Rose, Gregory V [mailto:gregory.v.r...@intel.com] > Sent: 29 February 2012 16:19 > To: James Bulpin; e1000-devel@lists.sourceforge.net > Subject: RE: igb hard-coded mac_table[0] in igb_probe > > > -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® Ethernet, visit http://communities.intel.com/community/wired
