From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by dpdk.org (Postfix) with ESMTP id 5AB3E2E8A for ; Mon, 30 Jan 2017 15:39:47 +0100 (CET) Received: by mail-wm0-f46.google.com with SMTP id c85so217311459wmi.1 for ; Mon, 30 Jan 2017 06:39:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=/IvVlFX9i7TxViRMKNTZpotS49FWFfYHCD14BvKKP0o=; b=k5BdtYWJ4dOQERNaWLw4ImJwObJYj7tsLFOpxraW7e7NL3TLWQQYTmVynTaMnWhX5m MtAKMDmq4m5ZVkzuEq3Gyp1lWGnTwhSavgs/Mcd6cGMR0Fw8bBJ/C8KTlD2h+DMA9on+ FzMVCfX+LP05+NQBLUXbmCL7sC91+bJe1yKJ62RXVm9c0usYS3bW/ZADFeU+JHFOoEZe OIaGQ8ELoaSCpgP5kdMOrxp/blHz6UzUfwbJLV2+Qs0p2yx+uKqibCZKH3xU98VIl1VQ PHNa2PuHtPnjdKir3AOiXD9udPg/EWQhAV+mCcERBZRfTpnGpU3wXfEHicw5Q4QxPcvu ZLbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=/IvVlFX9i7TxViRMKNTZpotS49FWFfYHCD14BvKKP0o=; b=Bvr95ig7gDscUg25qcPoQp0IrtUZlL3M2T3qPFzcbAF2C1HlVmUAMSymwfgW6+lAL+ aCKT+OJjzrjsLvvF058O4b86r9csqDPKzOBQJHnFGrgyeAuI3GatCE9m/vLrYKGRqV6E IDrXy7bCBgaLFgRCb1tQK95opDNC58Zz0zuJpk98DPkHebKANgnXwgPMdClxyEEUikgc osVyRVWgEkX5pp5XUhGx9yhrK+OF6KJXcb/EAtK0qFyCh453RG4WIr7Zl5LriBfOInn+ d7++n1eXDvyeALmowXAKYZ0fRcySj1iNcnmhONoCt2a1pExV1GdSF6e4BLW4haIj8hAH ovtA== X-Gm-Message-State: AIkVDXIV7AD+wd6phNEp1RmWbvsvlnHdb1c198PTHJU1g3amZhXm2Krhtcn423MhdfYrjAzD X-Received: by 10.28.48.78 with SMTP id w75mr15750672wmw.55.1485787186602; Mon, 30 Jan 2017 06:39:46 -0800 (PST) Received: from [10.16.0.184] (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id m188sm17768037wma.0.2017.01.30.06.39.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jan 2017 06:39:46 -0800 (PST) To: dev@dpdk.org References: <20170129021205.36860-1-keith.wiles@intel.com> <2c430141-94c1-5482-7fc2-94f5908b41e0@intel.com> From: Pascal Mazon Message-ID: Date: Mon, 30 Jan 2017 15:38:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: <2c430141-94c1-5482-7fc2-94f5908b41e0@intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] net/tap: driver closing tx interface on queue setup 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: Mon, 30 Jan 2017 14:39:47 -0000 On 01/30/2017 12:00 PM, Ferruh Yigit wrote:> On 1/29/2017 2:12 AM, Keith Wiles wrote: >> The tap driver setup both rx and tx file descriptors when the >> rte_eth_rx_queue_setup() causing the tx to be closed when tx setup >> was called. > > Can you please describe the problem more. > Without this patch rx->fd == tx->fd, with this patch rx and tx has > different file descriptors. > > What was the wrong with rx and tx having same fd? > > As far as I can see, rte_eth_rx_queue_setup() won't close tx->fd, that > function will do nothing if rx or tx has valid fd. > >> >> Signed-off-by: Keith Wiles > > <...> > Hi, The tap PMD recently broke for me because of this patch [1]. During init (eth_dev_tap_create()), the tap PMD allocates a shared RX/TX queue through tun_alloc(). The recent patch now releases existing queues in rx_queue_setup(), before adding new ones. When rx_queue_setup() is called, it uses close() calls on all shared queues, effectively deleting the netdevice. That's the main issue here. I tested Keith's patch [2], and it fixes that issue, using separate queues. There is however a couple of other queues-related issues in the tap PMD, but I'm not sure how to address them properly: 1. internals->fds[] gets filled only with RX queues (appart from index 0 that is common to both RX and TX). It means that RX queues only will be deleted when calling rte_pmd_tap_remove() or tap_tx_queue_release(). 2. tap_dev_stop() is not symmetrical with tap_dev_start(): queues won't get re-created after a stop. It may be best to keep the very first fd (created with tun_alloc() in eth_dev_tap_create() during probe) apart. And then add separate TX/RX queues in internals->txq[] and internals->rxq[] respectively. What do you think? [1] d00d7cc88335 ("ethdev: release queue before setting up") [2] http://dpdk.org/ml/archives/dev/2017-January/056470.html -- Pascal Mazon www.6wind.com