lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y/S6N6pcbHSFdj11@nanopsycho>
Date:   Tue, 21 Feb 2023 13:33:59 +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

Tue, Feb 21, 2023 at 12:54:25AM CET, shannon.nelson@....com wrote:
>On 2/20/23 12:22 AM, Jiri Pirko wrote:
>> 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.
>
>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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ