Re: [RFC][PATCH V2 1/3] examples/vhost: Add vswitch (generic switch) framework

["Tan, Jianfeng" <jianfeng.tan@intel.com>]

Hi Pankaj,

Thanks for the massive and great work.

On 9/5/2016 6:54 PM, Pankaj Chauhan wrote:
> Introduce support for a generic framework for handling of switching between
> physical and vhost devices. The vswitch framework introduces the following
> concept:
>
> 1. vswitch_dev: Vswitch device is a logical switch which can have physical and
> virtio devices. The devices are operated/used using standard rte_eth API for
> physical devices and lib_vhost API for vhost devices, PMD API is not used
> for vhost devices.
>
> 2. vswitch_port: Any physical or virtio device that is added to vswitch. The
> port can have its own tx/rx functions for doing data transfer, which are exposed
> to the framework using generic function pointers (vs_port->do_tx/do_rx). This way
> the generic code can do tx/rx without understanding the type of device (Physical or
> virtio). Similarly each port has its own functions to select tx/rx queues. The framework
> provides default tx/rx queue selection functions to the port when port is added
> (for both physical and vhost devices). But the framework allows the switch implementation
> to override the queue selection functions (vs_port->get_txq/rxq) if required.
>
> 3. vswitch_ops: The ops is set of function pointers which are used to do operations
> like learning, unlearning, add/delete port, lookup_and_forward. The user of vswitch
> framework (vhost/main.[c,h])uses these function pointers to perform above mentioned
> operations, thus it remains agnostic of the underlying implementation.
>
> Different switching logics can implement their vswitch_device and vswitch_ops, and
> register with the framework. This framework makes vhost-switch application scalable
> in terms of:
>
> 1. Different switching logics (one of them is vmdq, vhost/vmdq.[c,h]
> 2. Number of ports.
> 3. Policies of selecting ports for rx and tx.
>
> Signed-off-by: Pankaj Chauhan <pankaj.chauhan@nxp.com>

After this patch set, how's mapping relationship between cores and 
vswitch_dev? Old vhost example does not have the concept of switch, so 
each core is binded with some VDEVs. Now, we still keep original logic?

(a) If yes, provided that phys device could has no direct relationship 
with vdevs in other switching logics, we may need to bind those physical 
devices to cores too? In that case, switch_worker() will receiving pkts 
from all devices (phys or virtual) and dispatch, which looks like:

switch_worker() {
     FOR each port binding to this core {
          rx(port, pkts[], count);
          vs_lookup_n_fwd( information_needed );
     }
}

(b) If no, we may bind each core with n switches? If so, switch_worker() 
also need to be reworked to keep receiving pkts from all ports of the 
switch, and dispatch.

switch_worker() {
     FOR each switch binding to this core {
          FOR each port of switch {
              rx(port, pkts[], count);
              vs_lookup_n_fwd( information_needed );
         }
     }
}

In all, (1) we'd better not use vdev to find phys dev in switch_worker 
any more; (2) we'd better not differentiate phys device and virtual 
device in generic framework (it's just an attribute of vswitch_port.

What do you think?

Thanks,
Jianfeng