RE: [PATCH net-next 00/16] nfp: ctrl vNIC

quoted

quoted

quoted

quoted

quoted

quoted

quoted

What were your plans with pre-netdev config?

We need to pass come initial resource division. Generally the
consensus is to have these options exposed through devlink, let
the user configure them all and then to have a trigger that
would cause driver re-orchestration according to the new
values. The flow would look like
this:

-driver loads with defaults, inits hw and instantiates netdevs
-driver exposes config options via devlink -user sets up the
options -user pushes the "go" trigger -upon the trigger
command, devlink calls the driver re-init callback -driver
shuts down the current instances, re-initializes hw,
re-instantiates the netdevs

Makes sense?

I like the idea of a "go"/apply/reload trigger and extending devlink.
Do you plan on adding a way to persist the settings?  I'm
concerned NIC users may want to boot into the right mode once
it's set, without reloads and reconfigs upon boot.  Also is there
going to be a way to query the pending/running config?  Sounds
like we may want to expose three value sets - persistent/default,
running and pending/to be applied.

quoted

I don't think it is a good idea to introduce any kind of
configuration persistency in HW. I believe that user is the master
and he has all needed info. He can store it persistently, but it
is up to

him.

quoted

quoted

So basicaly during boot, we need the devlink configuration to
happen early on, before the netdevices get configured. udev? Not
sure how exactly to do this. Have to ask around :)

Thinking about use cases where we'd want information available at
probe time, it might have been even better to have it separated from
the netdevice, e.g., providing clients with node to configure
(generic?) information on top of their PCI nodes.

Yuval, devlink is separated from the netdevices....

Separate from the netdevices, yes. But I think it's still a networking facility.
I.e., would it make sense creating devlink nodes for PCI devices?

True that devlink is placed in net/core. But from the very beginning, it was
designed to be multipurpose. So not only for net devices, but for any device
where is is suitable.

quoted

Anyway, I don't think there's any *strong* need for what I was asking
for; It's simply that I was thinking of qed where there's quite a bit
going on during the pci probe, and thought how re-doing it can be avoided.

You can (should) register devlink early on way before netdevs.

Given that I can't really register it sooner than the PCI probe,
how would shortly-before or way-before differ?

Assume you have some userspace daemon monitoring devlink and applying
user-provided configuration.
How could it reliably apply the configuration between devlink registration
and netdevice registeration?

The merit of the udev suggestion was that the sync. point was in userspace,
so user could always make sure that devlink rules apply before netdev state changes.