netdev - Re: [PATCH net-next] net/mlx5: remove the recent devlink params

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] [day] [month] [year] [list]

Message-ID: <882632aaeaa3bbc8b6e2aa2c76bce5a065a22625.camel@nvidia.com>
Date:   Tue, 26 Oct 2021 19:11:26 +0000
From:   Saeed Mahameed <saeedm@...dia.com>
To:     Parav Pandit <parav@...dia.com>, Jiri Pirko <jiri@...dia.com>,
        "kuba@...nel.org" <kuba@...nel.org>
CC:     Leon Romanovsky <leonro@...dia.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] net/mlx5: remove the recent devlink params

On Tue, 2021-10-26 at 09:47 -0700, Jakub Kicinski wrote:
> On Tue, 26 Oct 2021 15:53:17 +0000 Parav Pandit wrote:
> > Hi Jakub,
> > 
> > > From: Jakub Kicinski <kuba@...nel.org>
> > > Sent: Tuesday, October 26, 2021 9:00 PM
> > > To: davem@...emloft.net
> > > Cc: Saeed Mahameed <saeedm@...dia.com>; netdev@...r.kernel.org;
> > > Leon
> > > Romanovsky <leonro@...dia.com>; Jakub Kicinski <kuba@...nel.org>
> > > Subject: [PATCH net-next] net/mlx5: remove the recent devlink
> > > params
> > > 
> > > revert commit 46ae40b94d88 ("net/mlx5: Let user configure
> > > io_eq_size
> > > param") revert commit a6cb08daa3b4 ("net/mlx5: Let user configure
> > > event_eq_size param") revert commit 554604061979 ("net/mlx5: Let
> > > user
> > > configure max_macs param")
> > > 
> > > The EQE parameters are applicable to more drivers, they should be
> > > configured
> > > via standard API, probably ethtool. Example of another driver
> > > needing
> > > something similar:  
> > 
> > ethool is not a good choice for following reasons.
> > 
> > 1. EQs of the mlx5 core devlink instance is used by multiple
> > auxiliary devices, namely net, rdma, vdpa.
> > 2. And sometime netdevice doesn't even exists to operate via
> > ethtool (but devlink instance exist to serve other devices).
> > 3. ethtool doesn't have notion set the config and apply (like
> > devlink reload)
> > Such reload operation is useful when user wants to configure more
> > than one parameter and initialize the device only once.
> > Otherwise dynamically changing parameter results in multiple device
> > re-init sequence that increases device setup time.
> 
> Sure these are good points. OTOH devlink doesn't have any notion of
> queues, IRQ vectors etc today so it doesn't really fit there, either.
> 

The point is, mlx5 has different architecture compared to other
vendors, EQs, IRQs are considered shared resources of upper layer
protocols/interfaces.

ethtool is netdev specific. 
EQ concept might not apply to all vendors even with last gen HW.

netdev/ethtool shouldn't be controlling concrete/arch specific
resources. better if we kept ethtool abstract (queues, rings, and
ethernet specific ..)


> > Should we define the devlink resources in the devlink layer,
> > instead of driver?
> 
> I'm not sure how the EQE fits into the existing devlink objects.
> params are not much of an API, it's a garbage bag.
> 

devlink is good place, it is what we decide it should be, a garbage bag
or a standard place for all generic networking device related knobs.

> > So that multiple drivers can make use of them without redefinition?
> 
> Yes, please.

let's send a RFC, CC Jiri of course and other vendors who might be
interested according to Jakub's grep (huawei/hinic, ibm/ehea,
microsoft/mana, qlogic/qed) ..