Re: [EXT] Re: [PATCH net-next v2 4/4] qed*: Add devlink support for configuration attributes.

[Jakub Kicinski <jakub.kicinski@netronome.com>]

On Fri, 5 Jul 2019 08:22:41 +0000, Sudarsana Reddy Kalluru wrote:
> > On Thu, 4 Jul 2019 06:20:11 -0700, Sudarsana Reddy Kalluru wrote:  
> > > This patch adds implementation for devlink callbacks for reading and
> > > configuring the device attributes.
> > >
> > > Signed-off-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> > > Signed-off-by: Ariel Elior <aelior@marvell.com>

> > > diff --git a/Documentation/networking/devlink-params-qede.txt
> > > b/Documentation/networking/devlink-params-qede.txt
> > > new file mode 100644
> > > index 0000000..f78a993
> > > --- /dev/null
> > > +++ b/Documentation/networking/devlink-params-qede.txt
> > > @@ -0,0 +1,72 @@
> > > +enable_sriov		[DEVICE, GENERIC]
> > > +			Configuration mode: Permanent
> > > +
> > > +iwarp_cmt		[DEVICE, DRIVER-SPECIFIC]
> > > +			Enable iWARP support over 100G device (CMT mode).  
> > > +			Type: Boolean
> > > +			Configuration mode: runtime
> > > +
> > > +entity_id		[DEVICE, DRIVER-SPECIFIC]
> > > +			Set the entity ID value to be used for this device
> > > +			while reading/configuring the devlink attributes.
> > > +			Type: u8
> > > +			Configuration mode: runtime  
> > 
> > Can you explain what this is?  
>
> Hardware/mfw provides the option to modify/read the config of other
> PFs. A non-zero entity id represents a partition number (or simply a
> PF-id) for which the config need to be read/updated.

Having a parameter which changes the interpretation of other parameters
makes me quite uncomfortable :(  Could it be a better idea, perhaps, to
use PCI ports?  We have been discussing PCI ports for a while now, and
they will probably become a reality soon.  You could then hang the
per-PF parameters off of the PF ports rather than the device instance? 

> > > +device_capabilities	[DEVICE, DRIVER-SPECIFIC]
> > > +			Set the entity ID value to be used for this device
> > > +			while reading/configuring the devlink attributes.
> > > +			Type: u8
> > > +			Configuration mode: runtime  
> > 
> > Looks like you copied the previous text here.  
> Will update it, thanks.
> 
> >   
> > > +mf_mode			[DEVICE, DRIVER-SPECIFIC]
> > > +			Configure Multi Function mode for the device.
> > > +			Supported MF modes and the assoicated values are,
> > > +			    MF allowed(0), Default(1), SPIO4(2), NPAR1.0(3),
> > > +			    NPAR1.5(4), NPAR2.0(5), BD(6) and UFP(7)  
> > 
> > NPAR should have a proper API in devlink port, what are the other modes?
> >   
> These are the different modes supported by the Marvell NIC. In our
> case the mf_mode is per adapter basis, e.g., it's not possible to
> configure one port in NPAR mode and the other in Default mode.

Jiri, what are your thoughts on the NPAR support?  It is effectively a
PCI split.  If we are going to support mdev split, should we perhaps
have a "depth" or "type" of split and allow for users to configure it
using the same API?

> > > +			Type: u8
> > > +			Configuration mode: Permanent
> > > +
> > > +dcbx_mode		[PORT, DRIVER-SPECIFIC]
> > > +			Configure DCBX mode for the device.
> > > +			Supported dcbx modes are,
> > > +			    Disabled(0), IEEE(1), CEE(2) and
> > > Dynamic(3)
> > > +			Type: u8
> > > +			Configuration mode: Permanent  
> > 
> > Why is this a permanent parameter?
> >   
> This specifies the dcbx_mode to be configured in non-volatile memory.
> The value is persistent and is used in the next load of OS or the mfw.

And it can't be changed at runtime?