Thread (40 messages) 40 messages, 7 authors, 2024-02-20

Re: [RFC PATCH v3 net-next] Documentation: devlink: Add devlink-sd

From: Jiri Pirko <jiri@resnulli.us>
Date: 2024-02-16 08:06:42

Fri, Feb 16, 2024 at 02:58:36AM CET, kuba@kernel.org wrote:
On Thu, 15 Feb 2024 14:19:40 +0100 Jiri Pirko wrote:
quoted
quoted
Maybe the first thing to iron out is the life cycle. Right now we
throw all configuration requests at the driver which ends really badly
for those of us who deal with heterogeneous environments. Applications
which try to do advanced stuff like pinning and XDP break because of
all the behavior differences between drivers. So I don't think we
should expose configuration of unstable objects (those which user
doesn't create explicitly - queues, irqs, page pools etc) to the driver.
The driver should get or read the config from the core when the object
is created.  
I see. But again, for global objects, I understand. But this is
device-specific object and configuration. How do you tie it up together?
We disagree how things should be modeled, sort of in principle.
I think it dates all the way back to your work on altnames.
We had the same conversation on DPLL :(

I prefer to give objects unique IDs and a bunch of optional identifying
attributes, rather than trying to build some well organized hierarchy.
The hierarchy often becomes an unnecessary constraint.
Sure, no problem on having floating objects with ids and attributes.
But in case they relate to HW configuration, you need to somehow glue
them to a device eventually. This is what I'm missing how you envision
it. The lifetime of object and glue/unglue operations.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help