[dpdk-dev] net/i40e: no more initial VF MAC address

Message ID 1484703940-2967-1-git-send-email-qi.z.zhang@intel.com (mailing list archive)
State Changes Requested, archived
Delegated to: Ferruh Yigit
Headers

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel compilation success Compilation OK

Commit Message

Qi Zhang Jan. 18, 2017, 1:45 a.m. UTC
  During PF initialization, PF will generate an initial mac
address for VFs, the purpose is to help VF keep a constant
mac address between startup/shutdown cycles. Now this is not
necessary, since we already provide an API to set VF mac
address from PF side (rte_pmd_i40e_set_vf_addr). Application
can use this API to lock down VF's mac address.
This change also sync DPDK PF's behavior with kernel driver.

Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
---
 drivers/net/i40e/i40e_pf.c | 1 -
 1 file changed, 1 deletion(-)
  

Comments

Ferruh Yigit Jan. 20, 2017, 5:39 p.m. UTC | #1
On 1/18/2017 1:45 AM, Qi Zhang wrote:
> During PF initialization, PF will generate an initial mac
> address for VFs, the purpose is to help VF keep a constant
> mac address between startup/shutdown cycles. 

I believe below does not provide permanent MAC address, PF assign a
random mac address to its VFs on each PF initialization.

> Now this is not
> necessary, since we already provide an API to set VF mac
> address from PF side (rte_pmd_i40e_set_vf_addr). 

rte_pmd_i40e_set_vf_mac_addr?

> Application
> can use this API to lock down VF's mac address.

As far as I can see how it was (before this patch):

1- During PF init, assign random MAC to VFs.
2- Application can overwrite VF MAC address with above API.
3- During VF init, if there is a valid MAC assigned by PF use it.
4- During VF init, if PF not assigned MAC, assign a random one.

So this patch removes above step 1.

Overall even if application will explicitly assign a MAC to VF or not,
VF will have a valid MAC address. So patch looks good, just please
reword commit log to describe above.

> This change also sync DPDK PF's behavior with kernel driver.
> 
> Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
> ---
>  drivers/net/i40e/i40e_pf.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/net/i40e/i40e_pf.c b/drivers/net/i40e/i40e_pf.c
> index ddfc140..4e05dca 100644
> --- a/drivers/net/i40e/i40e_pf.c
> +++ b/drivers/net/i40e/i40e_pf.c
> @@ -1053,7 +1053,6 @@ i40e_pf_host_init(struct rte_eth_dev *dev)
>  		ret = i40e_pf_host_vf_reset(&pf->vfs[i], 0);
>  		if (ret != I40E_SUCCESS)
>  			goto fail;
> -		eth_random_addr(pf->vfs[i].mac_addr.addr_bytes);
>  	}
>  
>  	/* restore irq0 */
>
  
Qi Zhang Feb. 22, 2017, 4:52 a.m. UTC | #2
Hi Ferruh:
	Sorry to reply this late, I think I missed your email.

> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Saturday, January 21, 2017 1:39 AM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> Zhang, Helin <helin.zhang@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] net/i40e: no more initial VF MAC address
> 
> On 1/18/2017 1:45 AM, Qi Zhang wrote:
> > During PF initialization, PF will generate an initial mac address for
> > VFs, the purpose is to help VF keep a constant mac address between
> > startup/shutdown cycles.
> 
> I believe below does not provide permanent MAC address, PF assign a random
> mac address to its VFs on each PF initialization.

Yes, this is for VF's startup /shutdown cycles only, but that's the original concern from customer.
> 
> > Now this is not
> > necessary, since we already provide an API to set VF mac address from
> > PF side (rte_pmd_i40e_set_vf_addr).
> 
> rte_pmd_i40e_set_vf_mac_addr?
Exactly!
> 
> > Application
> > can use this API to lock down VF's mac address.
> 
> As far as I can see how it was (before this patch):
> 
> 1- During PF init, assign random MAC to VFs.
> 2- Application can overwrite VF MAC address with above API.
> 3- During VF init, if there is a valid MAC assigned by PF use it.
> 4- During VF init, if PF not assigned MAC, assign a random one.
> 
> So this patch removes above step 1.

Yes, we remove step 1 intentionally to align with kernel PF driver's behavior, 
because for kernel VF, during initialization, once it found PF already assigned a valid MAC, it cannot be changed from VF anymore
but if it is not a valid address, VF is given the permission to change it.

> 
> Overall even if application will explicitly assign a MAC to VF or not, VF will have
> a valid MAC address. So patch looks good, just please reword commit log to
> describe above.


Sure, I will update the commit log
> 
> > This change also sync DPDK PF's behavior with kernel driver.
> >
> > Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
> > ---
> >  drivers/net/i40e/i40e_pf.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/net/i40e/i40e_pf.c b/drivers/net/i40e/i40e_pf.c
> > index ddfc140..4e05dca 100644
> > --- a/drivers/net/i40e/i40e_pf.c
> > +++ b/drivers/net/i40e/i40e_pf.c
> > @@ -1053,7 +1053,6 @@ i40e_pf_host_init(struct rte_eth_dev *dev)
> >  		ret = i40e_pf_host_vf_reset(&pf->vfs[i], 0);
> >  		if (ret != I40E_SUCCESS)
> >  			goto fail;
> > -		eth_random_addr(pf->vfs[i].mac_addr.addr_bytes);
> >  	}
> >
> >  	/* restore irq0 */
> >

Regards
Qi
  

Patch

diff --git a/drivers/net/i40e/i40e_pf.c b/drivers/net/i40e/i40e_pf.c
index ddfc140..4e05dca 100644
--- a/drivers/net/i40e/i40e_pf.c
+++ b/drivers/net/i40e/i40e_pf.c
@@ -1053,7 +1053,6 @@  i40e_pf_host_init(struct rte_eth_dev *dev)
 		ret = i40e_pf_host_vf_reset(&pf->vfs[i], 0);
 		if (ret != I40E_SUCCESS)
 			goto fail;
-		eth_random_addr(pf->vfs[i].mac_addr.addr_bytes);
 	}
 
 	/* restore irq0 */