Hi Pankaj, >> 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
