| Message ID | 20180322105522.8186-11-jiri@resnulli.us |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
| Series | devlink: introduce port flavours and common phys_port_name generation | expand |
On Thu, 22 Mar 2018 11:55:20 +0100, Jiri Pirko wrote: > From: Jiri Pirko <jiri@mellanox.com> > > Signed-off-by: Jiri Pirko <jiri@mellanox.com> > --- > drivers/net/ethernet/netronome/nfp/flower/main.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/net/ethernet/netronome/nfp/flower/main.c b/drivers/net/ethernet/netronome/nfp/flower/main.c > index aed8df0e9d41..1890af7e6196 100644 > --- a/drivers/net/ethernet/netronome/nfp/flower/main.c > +++ b/drivers/net/ethernet/netronome/nfp/flower/main.c > @@ -427,10 +427,9 @@ static int nfp_flower_vnic_alloc(struct nfp_app *app, struct nfp_net *nn, > goto err_invalid_port; > } > > - eth_hw_addr_random(nn->dp.netdev); > netif_keep_dst(nn->dp.netdev); > > - return 0; > + return nfp_app_nic_vnic_alloc(app, nn, id); > > err_invalid_port: > nn->port = nfp_port_alloc(app, NFP_PORT_INVALID, nn->dp.netdev); This will associate the PF netdev with physical port, incl. all ethtool information. Im not sure we want to do that. phy_repr carries this functionality.
Fri, Mar 23, 2018 at 04:38:28AM CET, jakub.kicinski@netronome.com wrote: >On Thu, 22 Mar 2018 11:55:20 +0100, Jiri Pirko wrote: >> From: Jiri Pirko <jiri@mellanox.com> >> >> Signed-off-by: Jiri Pirko <jiri@mellanox.com> >> --- >> drivers/net/ethernet/netronome/nfp/flower/main.c | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/drivers/net/ethernet/netronome/nfp/flower/main.c b/drivers/net/ethernet/netronome/nfp/flower/main.c >> index aed8df0e9d41..1890af7e6196 100644 >> --- a/drivers/net/ethernet/netronome/nfp/flower/main.c >> +++ b/drivers/net/ethernet/netronome/nfp/flower/main.c >> @@ -427,10 +427,9 @@ static int nfp_flower_vnic_alloc(struct nfp_app *app, struct nfp_net *nn, >> goto err_invalid_port; >> } >> >> - eth_hw_addr_random(nn->dp.netdev); >> netif_keep_dst(nn->dp.netdev); >> >> - return 0; >> + return nfp_app_nic_vnic_alloc(app, nn, id); >> >> err_invalid_port: >> nn->port = nfp_port_alloc(app, NFP_PORT_INVALID, nn->dp.netdev); > >This will associate the PF netdev with physical port, incl. all ethtool >information. Im not sure we want to do that. phy_repr carries this >functionality. I was not sure originally what this port is. Okay, what I would like to see is another port flavour for "pf" and "vf". I guess that since the pf has the same pci address, it would fall under the same devlink instance. For vfs, which have each separate pci address, I would like to create devlink instance for each and associate with one devlink port flavour "vf".
On Fri, 23 Mar 2018 07:29:41 +0100, Jiri Pirko wrote: > >This will associate the PF netdev with physical port, incl. all ethtool > >information. Im not sure we want to do that. phy_repr carries this > >functionality. > > I was not sure originally what this port is. Okay, what I would like to > see is another port flavour for "pf" and "vf". I guess that since the pf > has the same pci address, it would fall under the same devlink instance. > For vfs, which have each separate pci address, I would like to create > devlink instance for each and associate with one devlink port flavour > "vf". Why do we need a devlink instance and phys port name for vfs? Just wondering.. It seems they should be covered by having different bus address. For full coverage of all netdevs?
Sat, Mar 24, 2018 at 04:32:02AM CET, jakub.kicinski@netronome.com wrote: >On Fri, 23 Mar 2018 07:29:41 +0100, Jiri Pirko wrote: >> >This will associate the PF netdev with physical port, incl. all ethtool >> >information. Im not sure we want to do that. phy_repr carries this >> >functionality. >> >> I was not sure originally what this port is. Okay, what I would like to >> see is another port flavour for "pf" and "vf". I guess that since the pf >> has the same pci address, it would fall under the same devlink instance. >> For vfs, which have each separate pci address, I would like to create >> devlink instance for each and associate with one devlink port flavour >> "vf". > >Why do we need a devlink instance and phys port name for vfs? Just >wondering.. It seems they should be covered by having different bus >address. For full coverage of all netdevs? It is a matter of identification I believe. Pfs are under the same pci address for nfp right? I think that user has to see then and distinguish. For VFs and nfp, I agree this is probably not necessary, as the pci address is different and there is also a different driver name. But for mlx5 for example, the same driver name is shown for all netdevs including VFs.
diff --git a/drivers/net/ethernet/netronome/nfp/flower/main.c b/drivers/net/ethernet/netronome/nfp/flower/main.c index aed8df0e9d41..1890af7e6196 100644 --- a/drivers/net/ethernet/netronome/nfp/flower/main.c +++ b/drivers/net/ethernet/netronome/nfp/flower/main.c @@ -427,10 +427,9 @@ static int nfp_flower_vnic_alloc(struct nfp_app *app, struct nfp_net *nn, goto err_invalid_port; } - eth_hw_addr_random(nn->dp.netdev); netif_keep_dst(nn->dp.netdev); - return 0; + return nfp_app_nic_vnic_alloc(app, nn, id); err_invalid_port: nn->port = nfp_port_alloc(app, NFP_PORT_INVALID, nn->dp.netdev);