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

[Yuanhan Liu <yuanhan.liu@linux.intel.com>]

On Tue, Sep 27, 2016 at 05:05:41PM +0530, Pankaj Chauhan wrote:
> >Hi Pankaj,
> >
> >Again, apologize for late response: you see I was busy ;) Besides, I
> >need some time to think about it.
> >
> 
> Hi YLiu,
> 
> No issues with delayed response :)

Thanks!

> 
> >Generally, I think your ideal proposal looks good to me (well, I don't
> >see the need of port mask):
> 
> The idea of port mask was to give ability to the caller to choose which type
> of port to do rx from, Physical port or vhost port.

What's the need of it? If you register a port, don't you need pull
packets from it?

And you don't have to distinguish whether it's a physical port or vhost
port or not. If a port is registered, just pull it. Simple, right?

> >
> >    switch_worker() {
> >           rx_port = vs_sched_rx_port(vswit_dev_g, core_id)
> >           rx_q = rx_port->get_rxq(vs_port, vdev, code_id);
> >           rx_port->do_rx(rx_port, rxq, NULL, pktss, MAX_PKT_BURST);
> >
> >           vs_lookup_n_fwd(rx_port, pkts, rx_count, rxq);
> >    }
> >
> >The issue is, as you stated, VMDq it's bit tricky to handle. How about
> >the following proposal then?
> >
> >We don't have to register the nic queues while VMDq is used, since a
> >phys queue is bond to a virtio queue in this mode. That means only
> >virtio queues will be scheduled.
> >
> >The virtio do_rx might look like below then:
> >
> >    vmdq_rx() {
> >            rte_eth_rx_burst(port, queue_bond_to_this_virtio_queue, ...);
> >            rte_vhost_enqueue_burst(...) if any;
> >
> >            rte_vhost_dequeue_burst(...);
> >    }
> >
> 
> Okay so in that case, we won't do any rte_eth_rx_burst() when
> physical_port->do_rx is called, Correct?.

The physical port do_rx will not be called at all, since it will
not registered. In the VMDq case, only virtio port will be registered
(by your vs_add_port function).

> If yes then in vmdq.c we'll
> overwrite vs_port->do_rx of physical port with a vmdq_do_rx_phys() which
> does nothing. Or we can even have an option that vmdq.c doesn't return the
> physical port when vs_sched_rx_port() is called,

As stated, if you don't register it, then vs_sched_rx_port will return no
physical port.

	--yliu

> i think this later option
> is better to save some CPU cycles.
> 
> I think it is possible but i would prefer to overwrite vs_port->do_rx() for
> vmdq (in vmdq.c) with the implementation that you suggested. The framework
> provides this option, i.e the switch implementation can overwrite the
> vs_port->do_rx/do_tx if required to handle any special cases for example the
> case of vmdq <> vdev boding.
> 
> Thanks,
> Pankaj
> >	--yliu
> >
>