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:   Thu, 26 May 2022 12:47:51 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Ido Schimmel <idosch@...sch.org>, Ido Schimmel <idosch@...dia.com>,
        netdev@...r.kernel.org, davem@...emloft.net, pabeni@...hat.com,
        jiri@...dia.com, petrm@...dia.com, dsahern@...il.com,
        andrew@...n.ch, mlxsw@...dia.com
Subject: Re: [PATCH net-next 00/11] mlxsw: extend line card model by devices
 and info

Thu, May 26, 2022 at 11:05:53AM CEST, jiri@...nulli.us wrote:
>Wed, May 25, 2022 at 05:50:54PM CEST, kuba@...nel.org wrote:
>>On Wed, 25 May 2022 08:20:45 +0200 Jiri Pirko wrote:
>>> >We talked about this earlier in the thread, I think. If you need both
>>> >info and flash per LC just make them a separate devlink instance and
>>> >let them have all the objects they need. Then just put the instance
>>> >name under lc info.  
>>> 
>>> I don't follow :/ What do you mean be "separate devlink instance" here?
>>> Could you draw me an example?
>>
>>Separate instance:
>>
>>	for (i = 0; i < sw->num_lcs; i++) {
>>		devlink_register(&sw->lc_dl[i]);
>>		devlink_line_card_link(&sw->lc[i], &sw->lc_dl[i]);
>>	}
>>
>>then report that under the linecard
>>
>>	nla_nest_start(msg, DEVLINK_SUBORDINATE_INSTANCE);
>>	devlink_nl_put_handle(msg, lc->devlink);
>>	nla_nest_end(msg...)
>>
>>then user can update the linecard like any devlink instance, switch,
>>NIC etc. It's better code reuse and I don't see any downside, TBH.
>
>I think you already suggested something like that. What you mean is that
>linecard would be modeled as any other devlink instance. Sorry, but that
>does not make any sense to me at all :/ Should devlink port not be
>devlink port and rather modeled as a separate devlink instance too? Same
>to the rest of the objects we already have. Should we have a tree of
>same devlink objects each overloaded to some specific type. If yes, that
>is completely changing the devlink modelling.
>
>The handle of the devlink object is bus_name/dev_name. In other words,
>there is a device on a bus and for each you can create devlink instance.
>Linecards is not on a any bus, is is not modeled in /sys. What would be
>the handle?
>
>What you suggest seems to me like completely broken :/

After some thinking I think I understand why you suggest this.
The versions in dev info and dev flash is there on devlink instance level,
so you would like to reuse it.

But it does not click. Having devlink instance just for this feels very
artificial, unfitting and heavy. IDK.


>
>I don't understand the motivation :/ The only I can think of that you
>will have the same "devlink dev flash" mechanism, but that's it.
>I'm not sure I understand why we cannot resolve the flashing otherwise,
>for example as I suggested with "devlink lc info" and "devlink lc
>flash". What is wrong with that?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ