[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y/Mtr6hmSOy9xDGg@nanopsycho>
Date: Mon, 20 Feb 2023 09:22:07 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Shannon Nelson <shannon.nelson@....com>
Cc: netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
drivers@...sando.io, brett.creeley@....com
Subject: Re: [PATCH v3 net-next 01/14] devlink: add enable_migration parameter
Fri, Feb 17, 2023 at 11:55:45PM CET, shannon.nelson@....com wrote:
>Add a new device generic parameter to enable/disable support
>for live migration in the devlink device. This is intended
>primarily for a core device that supports other ports/VFs/SFs.
>Those dependent ports may need their own migratable parameter
>for individual enable/disable control.
>
>Examples:
> $ devlink dev param set pci/0000:07:00.0 name enable_migration value true cmode runtime
> $ devlink dev param show pci/0000:07:00.0 name enable_migration
> pci/0000:07:00.0:
> name enable_migration type generic
> values:
> cmode runtime value true
>
>Signed-off-by: Shannon Nelson <shannon.nelson@....com>
Could you please elaborate why exactly is this needed?
>From my perspective, the migration capability is something that
is related to the actual function (VF/SF).
When instantiating/configuring SF/VF, the admin ask for the particular
function to support live migration. We have port function caps now,
which is exactly where this makes sense.
See DEVLINK_PORT_FN_CAP_MIGRATABLE.
Powered by blists - more mailing lists