Re: [PATCH v3 net-next 2/2 tuntap: Increase the number of queues in tun.

On 12/04/2014 06:20 PM, Michael S. Tsirkin wrote:

On Thu, Dec 04, 2014 at 03:03:34AM +0008, Jason Wang wrote:

quoted

quoted

On Wed, Dec 3, 2014 at 5:52 PM, Michael S. Tsirkin [off-list ref] wrote:

quoted

quoted

On Wed, Dec 03, 2014 at 12:49:37PM +0530, Pankaj Gupta wrote:

quoted

quoted

Networking under kvm works best if we allocate a per-vCPU RX and TX
queue in a virtual NIC. This requires a per-vCPU queue on the host
side.
It is now safe to increase the maximum number of queues.
Preceding patche: 'net: allow large number of rx queues'

s/patche/patch/

quoted

quoted

made sure this won't cause failures due to high order memory
allocations. Increase it to 256: this is the max number of vCPUs
KVM supports.
Signed-off-by: Pankaj Gupta <redacted>
Reviewed-by: David Gibson <redacted>

Hmm it's kind of nasty that each tun device is now using x16 memory.
Maybe we should look at using a flex array instead, and removing the
limitation altogether (e.g. make it INT_MAX)?

But this only happens when IFF_MULTIQUEUE were used.

I refer to this field:
        struct tun_file __rcu   *tfiles[MAX_TAP_QUEUES];
if we make MAX_TAP_QUEUES 256, this will use 4K bytes,
apparently unconditionally.

How about just allocate one tfile if IFF_MULTIQUEUE were disabled?