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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 8 Jul 2019 02:31:15 +0000
From:   Sudarsana Reddy Kalluru <skalluru@...vell.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Michal Kalderon <mkalderon@...vell.com>,
        "Ariel Elior" <aelior@...vell.com>, Jiri Pirko <jiri@...nulli.us>
Subject: RE: [EXT] Re: [PATCH net-next v2 4/4] qed*: Add devlink support for
 configuration attributes.



> -----Original Message-----
> From: Jakub Kicinski <jakub.kicinski@...ronome.com>
> Sent: Saturday, July 6, 2019 1:09 AM
> To: Sudarsana Reddy Kalluru <skalluru@...vell.com>
> Cc: davem@...emloft.net; netdev@...r.kernel.org; Michal Kalderon
> <mkalderon@...vell.com>; Ariel Elior <aelior@...vell.com>; Jiri Pirko
> <jiri@...nulli.us>
> Subject: Re: [EXT] Re: [PATCH net-next v2 4/4] qed*: Add devlink support for
> configuration attributes.
> 
> 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@...vell.com>
> > > > Signed-off-by: Ariel Elior <aelior@...vell.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?
> 
Agree with you, thanks.

> > > > +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?
Run time dcbx params are not affected via this interface, it only updates config on permanent storage of the port.