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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).