| Message ID | 20221019140943.18851-3-simon.horman@corigine.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | nfp: support VF multi-queues configuration | expand |
On 19/10/2022 17:09, Simon Horman wrote: > From: Peng Zhang <peng.zhang@corigine.com> > > VF max-queue-number is the MAX num of queues which the VF has. > > Add new device generic parameter to configure the max-queue-number > of the each VF to be generated dynamically. > > The string format is decided ad vendor specific. The suggested > format is ...-V-W-X-Y-Z, the V represents generating V VFs that > have 16 queues, the W represents generating W VFs that have 8 > queues, and so on, the Z represents generating Z VFs that have > 1 queue. Having a vendor specific string contradicts the point of having a generic parameter, why not do it as a vendor param, or generalize the string? > > For example, to configure > * 1x VF with 128 queues > * 1x VF with 64 queues > * 0x VF with 32 queues > * 0x VF with 16 queues > * 12x VF with 8 queues > * 2x VF with 4 queues > * 2x VF with 2 queues > * 0x VF with 1 queue, execute: > > $ devlink dev param set pci/0000:01:00.0 \ > name max_vf_queue value \ > "1-1-0-0-12-2-2-0" cmode runtime > > When created VF number is bigger than that is configured by this > parameter, the extra VFs' max-queue-number is decided as vendor > specific. > > If the config doesn't be set, the VFs' max-queue-number is decided > as vendor specific. > > Signed-off-by: Peng Zhang <peng.zhang@corigine.com> > Signed-off-by: Simon Horman <simon.horman@corigine.com> > Does this command have to be run before the VFs are created? What happens to existing VFs?
On Sun, Oct 23, 2022 at 02:28:24PM +0300, Gal Pressman wrote: > [Some people who received this message don't often get email from gal@nvidia.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > On 19/10/2022 17:09, Simon Horman wrote: > > From: Peng Zhang <peng.zhang@corigine.com> > > > > VF max-queue-number is the MAX num of queues which the VF has. > > > > Add new device generic parameter to configure the max-queue-number > > of the each VF to be generated dynamically. > > > > The string format is decided ad vendor specific. The suggested > > format is ...-V-W-X-Y-Z, the V represents generating V VFs that > > have 16 queues, the W represents generating W VFs that have 8 > > queues, and so on, the Z represents generating Z VFs that have > > 1 queue. > > Having a vendor specific string contradicts the point of having a > generic parameter, why not do it as a vendor param, or generalize the > string? As Jakub suggested, we'll try to utilize devlink resource API instead. > > > > > For example, to configure > > * 1x VF with 128 queues > > * 1x VF with 64 queues > > * 0x VF with 32 queues > > * 0x VF with 16 queues > > * 12x VF with 8 queues > > * 2x VF with 4 queues > > * 2x VF with 2 queues > > * 0x VF with 1 queue, execute: > > > > $ devlink dev param set pci/0000:01:00.0 \ > > name max_vf_queue value \ > > "1-1-0-0-12-2-2-0" cmode runtime > > > > When created VF number is bigger than that is configured by this > > parameter, the extra VFs' max-queue-number is decided as vendor > > specific. > > > > If the config doesn't be set, the VFs' max-queue-number is decided > > as vendor specific. > > > > Signed-off-by: Peng Zhang <peng.zhang@corigine.com> > > Signed-off-by: Simon Horman <simon.horman@corigine.com> > > > > Does this command have to be run before the VFs are created? What > happens to existing VFs? Yes in our current implementation, but it's up to the vendor's implementation I think.
On Mon, Oct 24, 2022 at 09:47:13AM +0800, Yinjun Zhang wrote: > On Sun, Oct 23, 2022 at 02:28:24PM +0300, Gal Pressman wrote: > > [Some people who received this message don't often get email from gal@nvidia.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > > > On 19/10/2022 17:09, Simon Horman wrote: > > > From: Peng Zhang <peng.zhang@corigine.com> > > > > > > VF max-queue-number is the MAX num of queues which the VF has. > > > > > > Add new device generic parameter to configure the max-queue-number > > > of the each VF to be generated dynamically. > > > > > > The string format is decided ad vendor specific. The suggested > > > format is ...-V-W-X-Y-Z, the V represents generating V VFs that > > > have 16 queues, the W represents generating W VFs that have 8 > > > queues, and so on, the Z represents generating Z VFs that have > > > 1 queue. <...> > > > > Does this command have to be run before the VFs are created? What > > happens to existing VFs? > > Yes in our current implementation, but it's up to the vendor's > implementation I think. All vendors should give same look and feel for the users. It is very frustrating to find that same command should be run in different point of time just to perform same thing. Thanks
diff --git a/Documentation/networking/devlink/devlink-params.rst b/Documentation/networking/devlink/devlink-params.rst index 4e01dc32bc08..4b415b1acc9d 100644 --- a/Documentation/networking/devlink/devlink-params.rst +++ b/Documentation/networking/devlink/devlink-params.rst @@ -137,3 +137,8 @@ own name. * - ``event_eq_size`` - u32 - Control the size of asynchronous control events EQ. + * - ``max_vf_queue`` + - String + - Configure the queue of the each VF to be generated dynamically. When + created VF number is bigger than that is configured by this parameter, + the extra VFs' max-queue-number is decided as vendor specific. diff --git a/include/net/devlink.h b/include/net/devlink.h index ba6b8b094943..8cedc33c5992 100644 --- a/include/net/devlink.h +++ b/include/net/devlink.h @@ -498,6 +498,7 @@ enum devlink_param_generic_id { DEVLINK_PARAM_GENERIC_ID_ENABLE_IWARP, DEVLINK_PARAM_GENERIC_ID_IO_EQ_SIZE, DEVLINK_PARAM_GENERIC_ID_EVENT_EQ_SIZE, + DEVLINK_PARAM_GENERIC_ID_MAX_VF_QUEUE, /* add new param generic ids above here*/ __DEVLINK_PARAM_GENERIC_ID_MAX, @@ -556,6 +557,9 @@ enum devlink_param_generic_id { #define DEVLINK_PARAM_GENERIC_EVENT_EQ_SIZE_NAME "event_eq_size" #define DEVLINK_PARAM_GENERIC_EVENT_EQ_SIZE_TYPE DEVLINK_PARAM_TYPE_U32 +#define DEVLINK_PARAM_GENERIC_MAX_VF_QUEUE_NAME "max_vf_queue" +#define DEVLINK_PARAM_GENERIC_MAX_VF_QUEUE_TYPE DEVLINK_PARAM_TYPE_STRING + #define DEVLINK_PARAM_GENERIC(_id, _cmodes, _get, _set, _validate) \ { \ .id = DEVLINK_PARAM_GENERIC_ID_##_id, \ diff --git a/net/core/devlink.c b/net/core/devlink.c index 89baa7c0938b..c33f9040c570 100644 --- a/net/core/devlink.c +++ b/net/core/devlink.c @@ -5152,6 +5152,11 @@ static const struct devlink_param devlink_param_generic[] = { .name = DEVLINK_PARAM_GENERIC_EVENT_EQ_SIZE_NAME, .type = DEVLINK_PARAM_GENERIC_EVENT_EQ_SIZE_TYPE, }, + { + .id = DEVLINK_PARAM_GENERIC_ID_MAX_VF_QUEUE, + .name = DEVLINK_PARAM_GENERIC_MAX_VF_QUEUE_NAME, + .type = DEVLINK_PARAM_GENERIC_MAX_VF_QUEUE_TYPE, + }, }; static int devlink_param_generic_verify(const struct devlink_param *param)