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
| ||
|
Date: Wed, 13 Jul 2022 11:03:20 +0800 From: "Zhu, Lingshan" <lingshan.zhu@...el.com> To: Parav Pandit <parav@...dia.com>, "jasowang@...hat.com" <jasowang@...hat.com>, "mst@...hat.com" <mst@...hat.com> Cc: "virtualization@...ts.linux-foundation.org" <virtualization@...ts.linux-foundation.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "xieyongji@...edance.com" <xieyongji@...edance.com>, "gautam.dawar@....com" <gautam.dawar@....com> Subject: Re: [PATCH V3 5/6] vDPA: answer num of queue pairs = 1 to userspace when VIRTIO_NET_F_MQ == 0 On 7/13/2022 12:48 AM, Parav Pandit wrote: >> From: Zhu, Lingshan <lingshan.zhu@...el.com> >> Sent: Sunday, July 10, 2022 10:30 PM >>> 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. >>> 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? > 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. > There is ambiguity for user space what to do with it and so in the kernel space.. > Instead of dealing with them differently in kernel, at present we attach each netlink attribute to a respective feature bit wherever applicable. > 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. I think it is still uniform, it there is _MQ, we return cfg.max_queue_pair, if no _MQ, return 1, still by netlink. Thanks
Powered by blists - more mailing lists