From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id BFA312E8A for ; Mon, 30 Jan 2017 16:05:15 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga105.jf.intel.com with ESMTP; 30 Jan 2017 07:05:14 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,311,1477983600"; d="scan'208";a="928190857" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga003.jf.intel.com with ESMTP; 30 Jan 2017 07:05:14 -0800 Received: from fmsmsx157.amr.corp.intel.com (10.18.116.73) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 30 Jan 2017 07:04:11 -0800 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.230]) by FMSMSX157.amr.corp.intel.com ([169.254.14.122]) with mapi id 14.03.0248.002; Mon, 30 Jan 2017 07:04:10 -0800 From: "Wiles, Keith" To: Pascal Mazon CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] net/tap: driver closing tx interface on queue setup Thread-Index: AQHSeugNf/Oo2Oh9K0+Thn0jLxcaCaFRnUAAgAAHPoA= Date: Mon, 30 Jan 2017 15:04:09 +0000 Message-ID: References: <20170129021205.36860-1-keith.wiles@intel.com> <2c430141-94c1-5482-7fc2-94f5908b41e0@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.252.137.159] Content-Type: text/plain; charset="us-ascii" Content-ID: <7E5DCC76B11D1D44AB7A533C92492E44@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 15:05:16 -0000 > On Jan 30, 2017, at 8:38 AM, Pascal Mazon wrote: >=20 > 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. >>=20 >> Can you please describe the problem more. >> Without this patch rx->fd =3D=3D tx->fd, with this patch rx and tx has >> different file descriptors. >>=20 >> What was the wrong with rx and tx having same fd? >>=20 >> 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. >>=20 >>>=20 >>> Signed-off-by: Keith Wiles >>=20 >> <...> >>=20 >=20 > Hi, >=20 > The tap PMD recently broke for me because of this patch [1]. >=20 > 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. >=20 > When rx_queue_setup() is called, it uses close() calls on all shared queu= es, effectively deleting the netdevice. > That's the main issue here. >=20 > I tested Keith's patch [2], and it fixes that issue, using separate queue= s. >=20 > There is however a couple of other queues-related issues in the tap PMD, = but I'm not sure how to address them properly: >=20 > 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_r= emove() or tap_tx_queue_release(). >=20 > 2. tap_dev_stop() is not symmetrical with tap_dev_start(): queues won't g= et re-created after a stop. >=20 > 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? >=20 > [1] d00d7cc88335 ("ethdev: release queue before setting up") > [2] http://dpdk.org/ml/archives/dev/2017-January/056470.html Lets keep the current patch just to get over the current problem if everyon= e agrees. I will address the comments Pascal brings up as a later updated t= o the TAP PMD or I can try to get the other issues cleaned up. >=20 >=20 > --=20 > Pascal Mazon > www.6wind.com Regards, Keith