From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 7080E1B10D for ; Wed, 3 Oct 2018 18:31:09 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2018 09:31:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,336,1534834800"; d="scan'208";a="79583053" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.49]) ([10.237.221.49]) by orsmga006.jf.intel.com with ESMTP; 03 Oct 2018 09:31:04 -0700 To: Thomas Monjalon , Raslan Darawsheh Cc: dev@dpdk.org, "keith.wiles@intel.com" , Shahaf Shuler , Ori Kam References: <1538047196-13789-2-git-send-email-rasland@mellanox.com> <1538476438-20891-1-git-send-email-rasland@mellanox.com> <1538476438-20891-2-git-send-email-rasland@mellanox.com> <1910504.ryvcqbe86A@xps> From: Ferruh Yigit Openpgp: preference=signencrypt Message-ID: <499593ee-22cf-7f2d-f004-a4486468b87c@intel.com> Date: Wed, 3 Oct 2018 17:31:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1910504.ryvcqbe86A@xps> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v4 2/2] net/tap: add queues when attaching from secondary process X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 16:31:10 -0000 On 10/2/2018 11:43 AM, Thomas Monjalon wrote: > 02/10/2018 12:34, Raslan Darawsheh: >> --- a/doc/guides/rel_notes/release_18_11.rst >> +++ b/doc/guides/rel_notes/release_18_11.rst >> @@ -67,6 +67,10 @@ New Features >> SR-IOV option in Hyper-V and Azure. This is an alternative to the previous >> vdev_netvsc, tap, and failsafe drivers combination. >> >> +* **Added TAP Rx/Tx queues sharing with a secondary process.** >> + >> + A secondary process can attach a TAP device created in the primary process, >> + probe the queues, and process Rx/Tx in a secondary process. > > A blank line is missing here. > >> @@ -2006,9 +2115,23 @@ rte_pmd_tap_probe(struct rte_vdev_device *dev) >> TAP_LOG(ERR, "Failed to probe %s", name); >> return -1; >> } >> - /* TODO: request info from primary to set up Rx and Tx */ >> eth_dev->dev_ops = &ops; >> eth_dev->device = &dev->device; >> + eth_dev->rx_pkt_burst = pmd_rx_burst; >> + eth_dev->tx_pkt_burst = pmd_tx_burst; >> + if (!rte_eal_primary_proc_alive(NULL)) { >> + TAP_LOG(ERR, "Primary process is missing"); >> + return -1; >> + } >> + process_private = (struct pmd_process_private *) >> + rte_zmalloc_socket(name, >> + sizeof(struct pmd_process_private), >> + RTE_CACHE_LINE_SIZE, >> + eth_dev->device->numa_node); >> + >> + ret = tap_mp_attach_queues(name, eth_dev); >> + if (ret != 0) >> + return -1; >> rte_eth_dev_probing_finish(eth_dev); >> return 0; >> } > > Should we manage rte_pmd_tun_probe too? I was about to ask same one, they share dev_ops, so tun also should be supporting multiple queue, if so why not update it?