From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 1EB7F37B1 for ; Mon, 19 Sep 2016 14:42:17 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP; 19 Sep 2016 05:42:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,361,1470726000"; d="scan'208";a="881436867" Received: from shwdeisgchi083.ccr.corp.intel.com (HELO [10.239.67.193]) ([10.239.67.193]) by orsmga003.jf.intel.com with ESMTP; 19 Sep 2016 05:42:15 -0700 To: Pankaj Chauhan , dev@dpdk.org 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> <23bebfde-54ad-04fd-64cb-c99d7a4a78e9@nxp.com> Cc: hemant.agrawal@nxp.com, yuanhan.liu@linux.intel.com, maxime.coquelin@redhat.com From: "Tan, Jianfeng" Message-ID: <764c0561-2325-56e9-51e3-f75285044ee4@intel.com> Date: Mon, 19 Sep 2016 20:42:15 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <23bebfde-54ad-04fd-64cb-c99d7a4a78e9@nxp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC][PATCH V2 1/3] examples/vhost: Add vswitch (generic switch) framework X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 12:42:18 -0000 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