[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <68b0f6e2-6890-46f9-b824-2af5ba5f9fd4@kernel.org>
Date: Thu, 11 Apr 2024 20:06:17 -0600
From: David Ahern <dsahern@...nel.org>
To: "Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
Parav Pandit <parav@...dia.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"stephen@...workplumber.org" <stephen@...workplumber.org>
Cc: Jiri Pirko <jiri@...dia.com>, Shay Drori <shayd@...dia.com>
Subject: Re: [PATCH v2 0/2] devlink: Support setting max_io_eqs
On 4/11/24 5:03 PM, Samudrala, Sridhar wrote:
>
>
> On 4/10/2024 9:32 PM, Parav Pandit wrote:
>> Hi Sridhar,
>>
>>> From: Samudrala, Sridhar <sridhar.samudrala@...el.com>
>>> Sent: Thursday, April 11, 2024 4:53 AM
>>>
>>>
>>> On 4/10/2024 6:58 AM, Parav Pandit wrote:
>>>> Devices send event notifications for the IO queues, such as tx and rx
>>>> queues, through event queues.
>>>>
>>>> Enable a privileged owner, such as a hypervisor PF, to set the number
>>>> of IO event queues for the VF and SF during the provisioning stage.
>>>
>>> How do you provision tx/rx queues for VFs & SFs?
>>> Don't you need similar mechanism to setup max tx/rx queues too?
>>
>> Currently we don’t. They are derived from the IO event queues.
>> As you know, sometimes more txqs than IO event queues needed for XDP,
>> timestamp, multiple TCs.
>> If needed, probably additional knob for txq, rxq can be added to
>> restrict device resources.
>
> Rather than deriving tx and rx queues from IO event queues, isn't it
> more user friendly to do the other way. Let the host admin set the max
> number of tx and rx queues allowed and the driver derive the number of
> ioevent queues based on those values. This will be consistent with what
> ethtool reports as pre-set maximum values for the corresponding VF/SF.
>
I agree with this point: IO EQ seems to be a mlx5 thing (or maybe I have
not reviewed enough of the other drivers). Rx and Tx queues are already
part of the ethtool API. This devlink feature is allowing resource
limits to be configured, and a consistent API across tools would be
better for users.
Powered by blists - more mailing lists