On 7/13/2022 11:06 AM, Parav Pandit wrote:

quoted

From: Zhu, Lingshan <redacted>
Sent: Tuesday, July 12, 2022 11:03 PM


On 7/13/2022 12:48 AM, Parav Pandit wrote:

quoted

quoted

From: Zhu, Lingshan <redacted>
Sent: Sunday, July 10, 2022 10:30 PM

quoted

Showing max_vq_pairs of 1 even when _MQ is not negotiated,
incorrectly

says that max_vq_pairs is exposed to the guest, but it is not offered.

quoted

So, please fix the iproute2 to not print max_vq_pairs when it is not

returned by the kernel.
iproute2 can report whether there is MQ feature in the device /
driver feature bits.
I think iproute2 only queries the number of max queues here.

max_vq_pairs shows how many queue pairs there, this attribute's
existence does not depend on MQ, if no MQ, there are still one queue
pair, so just show one.

This netlink attribute's existence is depending on the _MQ feature bit

existence.
why? If no MQ, then no queues?

quoted

We can break that and report the value, but if we break that there are

many other config space bits who doesn’t have good default like
max_vq_pairs.
max_vq_paris may not have a default value, but we know if there is no MQ,
a virtio-net still have one queue pair to be functional.

quoted

There is ambiguity for user space what to do with it and so in the kernel

space..

quoted

Instead of dealing with them differently in kernel, at present we attach

each netlink attribute to a respective feature bit wherever applicable.

quoted

And code in kernel and user space is uniform to handle them.

I get your point, but you see, by "max_vq_pairs", the user space tool is
asking how many queue pairs there, it is not asking whether the device have
MQ.
Even no _MQ, we still need to tell the users that there are one queue pair, or
it is not a functional virtio-net, we should detect this error earlier in the
device initialization.

It is not an error. :)

I meant if no queues, it should be non-functional, which is an error.

When the user space which invokes netlink commands, detects that _MQ is not supported, hence it takes max_queue_pair = 1 by itself.

I think the kernel module have all necessary information and it is the 
only one which have precise information of a device, so it
should answer precisely than let the user space guess. The kernel module 
should be reliable than stay silent, leave the question
to the user space tool.

quoted

I think it is still uniform, it there is _MQ, we return cfg.max_queue_pair, if no
_MQ, return 1, still by netlink.

Better to do that in user space because we cannot do same for other config fields.

same as above

quoted

Thanks