On 04.02.26 01:53, Ilya Maximets wrote:
On 2/3/26 9:21 PM, Chaney, Ben wrote:
Perhaps the condition here should be opts->queues > MAX_TAP_QUEUES
instead of UINT_MAX
I wonder why would we use MAX_TAP_QUEUES for something that isn't
a tap interface? It's also not defined here, would be a bit awkward
to export.
Fair point. It looks like I got my wires crossed a bit here. (And also in my
comment to the other patch). Would it be possible to have different
MAX_XYZ_QUEUES for other device types?
Why do we need an artificial limit on the number of queues?
In the kernel the number of queues per device is not limited,
it just needs to fit into unsigned int. So, I don't think
we need to create artificial limits on QEMU side.
AFAIU, the MAX_TAP_QUEUES was introduced because implementation
allocated an array of that size on stack and it is not wise
to do so with a fairly unbound values. But today even tap.c
allocates everything dynamically, so I'm not even sure if the
MAX_TAP_QUEUES makes much sense for net/tap itself, as it seems
to be an artificial limit for the number of fds that can be
passed in. It is also no enforced when QEMU creates the queues
on its own.
Best regards, Ilya Maximets.
Right, MAX_TAP_QUEUES is artificial for tap.c, and becomes absolutely
unused after this series. Still, I forget to remove the macro itself.
--
Best regards,
Vladimir
