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.
