Hi Pankaj,

quoted

Can we hide queues inside struct vswitch_port? I mean:
For VMDQ switch, treat (port_id, queue_id) as a vswitch_port, so far
you've already stored "struct vhost_dev *" into vswitch_port.priv when
it's a virtual port, how about store queue_id into vswitch_port.priv
when it's a physical port.
For arp_learning switch, make (port_id, all_enabled_queues) as a
vswitch_port.
Summarize above two: we treat (port_id, all_enabled_queues[]) as a
vswitch_port.

How about it?

Thanks for wonderful suggestion! Yes it should be possible, instead of 
having one vs_port for physical device we could create one vs_port for 
each phys device + queue_id combination.

Then we can bind the vs_ports to the cores, and do away with binding 
vdevs to the cores.

In order to add extra vs_ports (port + queue_id) there are two methods:

1. vhost/main.c (or vswitch_common.c) queries the underlying switch 
about how many rx queues to support thourgh a new accessor. VMDQ will 
return the number of vmdq queues, in this case. After getting the 
number of rx queues, vhost/main.c creates the extra ports i.e one 
vs_port for each physical port and queue id combination.

2. Second method is that the switch implementation for example vmdq.c 
create the extra ports (port + queue_id) as part of vs_port->add_port 
operation for the physical port.

Which method do you think we should follow? I think #1 should be done 
so that same logic can be used for other switches also.

Although VMDQs are created at initialization, we will not connect all of 
them to switch until a virtio device is added. So how about creating 
extra vs_ports (port + queue_id) as part of vmdq_add_port_virtio()?

Another thing, why we need the accessor, port_start()? For physical 
ports, it's initialized and started at port_init(); for virtual ports, 
no need to get started, right?

Thanks,
Jianfeng