[Intel-wired-lan] [net-next 03/10] fm10k: don't store sw_vid at reset

Alexander Duyck alexander.duyck at gmail.com
Sat Jun 20 04:03:30 UTC 2015


On 06/19/2015 04:37 PM, Jacob Keller wrote:
> If we store the sw_vid at reset of PF, then we accidentally prevent the
> VF from receiving the message to update its default VID. This only
> occurs if the VF is created before the PF has come up, which is the
> standard way of creating VFs when using the module parameter.

The upstream driver doesn't have a module parameter for VFs.  It uses 
sysfs.  It isn't clear but can this issue occur if you use the sysfs?

> This fixes an issue where we request the incorrect MAC/VLAN
> combinations, and prevents us from accidentally reporting some frames as
> vlan tagged.
>
> Signed-off-by: Jacob Keller <jacob.e.keller at intel.com>
> ---
>   drivers/net/ethernet/intel/fm10k/fm10k_iov.c | 3 ---
>   1 file changed, 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_iov.c b/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
> index 94571e6e790c..0e25a80417b9 100644
> --- a/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
> +++ b/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
> @@ -228,9 +228,6 @@ int fm10k_iov_resume(struct pci_dev *pdev)
>   		hw->iov.ops.set_lport(hw, vf_info, i,
>   				      FM10K_VF_FLAG_MULTI_CAPABLE);
>   
> -		/* assign our default vid to the VF following reset */
> -		vf_info->sw_vid = hw->mac.default_vid;
> -
>   		/* mailbox is disconnected so we don't send a message */
>   		hw->iov.ops.assign_default_mac_vlan(hw, vf_info);
>   

The patch itself looks fine.  I assume the Switch API will send a 
message to force us onto the correct VID if there is one already 
reserved for this VF.

I probably shouldn't have used the PF VLAN ID for the VFs anyway. Just 
letting the Switch API bounce a message through is a much better way to go.


More information about the Intel-wired-lan mailing list