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 <skall...@marvell.com> > > > Signed-off-by: Ariel Elior <ael...@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?
