From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yuanhan Liu Subject: Re: [RFC][PATCH V2 1/3] examples/vhost: Add vswitch (generic switch) framework Date: Tue, 27 Sep 2016 20:10:45 +0800 Message-ID: <20160927121045.GN25823@yliu-dev.sh.intel.com> References: <1473072871-16108-1-git-send-email-pankaj.chauhan@nxp.com> <1473072871-16108-2-git-send-email-pankaj.chauhan@nxp.com> <84848c11-fc26-015f-b7f8-a27d0558ef0b@nxp.com> <20160919144303.GL23158@yliu-dev.sh.intel.com> <9807e34b-6553-7a10-516b-2c59ad5c667d@nxp.com> <20160926035607.GJ23158@yliu-dev.sh.intel.com> <2d3dbd38-7dba-3af4-ab0e-52bc48f861d6@nxp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Tan, Jianfeng" , dev@dpdk.org, hemant.agrawal@nxp.com, maxime.coquelin@redhat.com To: Pankaj Chauhan Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 74FE912A8 for ; Tue, 27 Sep 2016 14:10:17 +0200 (CEST) Content-Disposition: inline In-Reply-To: <2d3dbd38-7dba-3af4-ab0e-52bc48f861d6@nxp.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 > > >