From: Jiri Pirko <jiri@resnulli.us>
To: Shannon Nelson <shannon.nelson@amd.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
drivers@pensando.io, brett.creeley@amd.com
Subject: Re: [PATCH v3 net-next 01/14] devlink: add enable_migration parameter
Date: Tue, 21 Feb 2023 13:33:59 +0100 [thread overview]
Message-ID: <Y/S6N6pcbHSFdj11@nanopsycho> (raw)
In-Reply-To: <98cd205b-fabe-a2ee-e9c0-51e269b78976@amd.com>
Tue, Feb 21, 2023 at 12:54:25AM CET, shannon.nelson@amd.com wrote:
>On 2/20/23 12:22 AM, Jiri Pirko wrote:
>> Fri, Feb 17, 2023 at 11:55:45PM CET, shannon.nelson@amd.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@amd.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.
>
>Hi Jiri,
>
>Thanks for your questions. My apologies for not getting your name into the
>To: list – a late Friday afternoon miss.
>
>This enable_migration flag is intended to be similar to the enable_vnet,
>enable_rdma, and similar existing parameters that are used by other core
>devices.
>
>Our pds_core device can be used to support several features (currently VFio
>and vDPA), and this gives the user a way to control how many of the features
>are made available in any particular configuration. This is to be enabled to
>turn on support for our pds_vfio client devices as a whole, not individually
>port-by-port. I understand FN_CAP_MIGRATABLE to be applied to an individual
>devlink port, which could be used in conjunction with this once the general
>feature is enable in pds_core.
Okay, that sounds legit. Could yout please extend the patch description
with this? Thanks!
>
>Thanks,
>sln
next prev parent reply other threads:[~2023-02-21 12:34 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-17 22:55 [PATCH v3 net-next 00/14] pds_core driver Shannon Nelson
2023-02-17 22:55 ` [PATCH v3 net-next 01/14] devlink: add enable_migration parameter Shannon Nelson
2023-02-20 8:22 ` Jiri Pirko
2023-02-20 23:54 ` Shannon Nelson
2023-02-21 12:33 ` Jiri Pirko [this message]
2023-02-21 21:55 ` Shannon Nelson
2023-02-20 8:23 ` Jiri Pirko
2023-02-17 22:55 ` [PATCH v3 net-next 02/14] pds_core: initial framework for pds_core driver Shannon Nelson
2023-02-17 22:55 ` [PATCH v3 net-next 03/14] pds_core: add devcmd device interfaces Shannon Nelson
2023-02-17 22:55 ` [PATCH v3 net-next 04/14] pds_core: health timer and workqueue Shannon Nelson
2023-02-17 22:55 ` [PATCH v3 net-next 05/14] pds_core: set up device and adminq Shannon Nelson
2023-02-17 22:55 ` [PATCH v3 net-next 06/14] pds_core: Add adminq processing and commands Shannon Nelson
2023-02-17 22:55 ` [PATCH v3 net-next 07/14] pds_core: add FW update feature to devlink Shannon Nelson
2023-02-17 22:55 ` [PATCH v3 net-next 08/14] pds_core: set up the VIF definitions and defaults Shannon Nelson
2023-02-17 22:55 ` [PATCH v3 net-next 09/14] pds_core: initial VF configuration Shannon Nelson
2023-02-17 22:55 ` [PATCH v3 net-next 10/14] pds_core: add auxiliary_bus devices Shannon Nelson
2023-02-17 22:55 ` [PATCH v3 net-next 11/14] pds_core: devlink params for enabling VIF support Shannon Nelson
2023-02-17 22:55 ` [PATCH v3 net-next 12/14] pds_core: add the aux client API Shannon Nelson
2023-02-17 22:55 ` [PATCH v3 net-next 13/14] pds_core: publish events to the clients Shannon Nelson
2023-02-17 22:55 ` [PATCH v3 net-next 14/14] pds_core: Kconfig and pds_core.rst Shannon Nelson
2023-02-18 2:48 ` kernel test robot
2023-02-19 10:11 ` [PATCH v3 net-next 00/14] pds_core driver Leon Romanovsky
2023-02-20 23:53 ` Shannon Nelson
2023-02-21 6:53 ` Leon Romanovsky
2023-02-21 22:03 ` Shannon Nelson
2023-02-22 7:59 ` Leon Romanovsky
2023-02-25 22:57 ` Shannon Nelson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y/S6N6pcbHSFdj11@nanopsycho \
--to=jiri@resnulli.us \
--cc=brett.creeley@amd.com \
--cc=davem@davemloft.net \
--cc=drivers@pensando.io \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=shannon.nelson@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.