From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 24A7F1B77A for ; Wed, 9 May 2018 23:59:43 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7E949221B8; Wed, 9 May 2018 17:59:40 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 09 May 2018 17:59:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=rgMOWNPiE3w7BXNxnEHgB8zjPu paDO/iz4F0LJmLt6Q=; b=R4mbAWyGouUlczNv8DrlRxi2VVNojeQBs5JmF5EQow C904fYaCOBqoFYPNTlMTumQ0Z5cahb8CwzGqvJM9DO5QzMyFzBp1O/gjcyvcBgVr NGNQ0eG4olm03b8KyIeiN1QZZRlLI7hUSpyzJXT0G3ORWr8hjfNX29f/+UI0BzFJ k= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=rgMOWN PiE3w7BXNxnEHgB8zjPupaDO/iz4F0LJmLt6Q=; b=LFws2UhQIAzalCZll8sAC6 GcDlYCXZfHhxEvehsoXQd3vK7MI3VqyFg83mnCQpw6j/ClynAWLFjm5qa9Tjn9NB yPe1I/0cQwP5Mjt+SHMnMqblZqKPkUvi1bffPlbZI7uMtCBmpih7mbX0rU5G5SzG 8rd5w4CA3xP6M/KNC2hlGnDeXto/1d5/lvywrQA7VIZc4laewakxR/TqkpZ1IWVe rQ4lfDuuWm6oCjyV4O+BlMb6pN9Auu6Fr7CJOrqrZ0VEx2lEX4C1ftnbALyGUkc5 OIs5PTdDMtt2M5otVULHaKHb6lkg4wPVBmfGKKdFnxKtgDZ2JnfzGEKXyIJVowuQ == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id BB685E43E8; Wed, 9 May 2018 17:59:39 -0400 (EDT) From: Thomas Monjalon To: =?ISO-8859-1?Q?Ga=EBtan?= Rivet Cc: Matan Azrad , "dev@dpdk.org" Date: Wed, 09 May 2018 23:59:38 +0200 Message-ID: <1590623.ITgNNa1ZXG@xps> In-Reply-To: <20180509140333.kb6pmbno2ixzuj7p@bidouze.vm.6wind.com> References: <20180509094337.26112-1-thomas@monjalon.net> <10613870.Sdbp1i1ck2@xps> <20180509140333.kb6pmbno2ixzuj7p@bidouze.vm.6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH 10/11] net/failsafe: fix sub-device ownership race 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, 09 May 2018 21:59:43 -0000 09/05/2018 16:03, Ga=EBtan Rivet: > On Wed, May 09, 2018 at 03:43:31PM +0200, Thomas Monjalon wrote: > > 09/05/2018 15:30, Ga=EBtan Rivet: > > > On Wed, May 09, 2018 at 01:01:58PM +0000, Matan Azrad wrote: > > > > Regarding uint32 > > > > The maximum port id number can be 0xffff. > > > > In this case the loop will be infinite if we use uint16 to iterate = over all the ports. > > >=20 > > > If RTE_MAX_ETHPORTS is set to 0xffff, an array rte_eth_devices[0xffff] > > > would be defined statically, and I think other issues would arise > > > before our being stuck in an infinite loop? > > >=20 > > > In any case, if this had to be fixed, then there should be a > > > BUILD_BUG_ON RTE_MAX_ETHPORTS being 0xffff, in the relevant part of > > > librte_ethdev, instead of relying on librte_ethdev users skirting > > > shortfalls of the library. Anyone iterating on port IDs should expect= the > > > port_id type to be sufficient to hold this information. > >=20 > > Interesting thought. > > I vote for keeping Matan's option as it is correct, > > and will accept a patch in 18.08 for your option (BUILD_BUG_ON). > > Maybe we should send a deprecation notice before limiting the max > > number of ports to 0xfffe? Or is it ridiculous for such unlikely constr= aint? > >=20 > >=20 >=20 > No actually the issue is when RTE_MAX_ETHPORTS is equal (or superior) to > 0x10000. >=20 > If this is an issue that you think is worth having a workaround here, > you should also consider that rte_eth_find_next_owned_by (and > rte_eth_find_next, even if this one should be phased out), would also > result in an overflow and an infinite loop. You get a point. I will remove the workaround uint32_t in v2, so all the related issues can be fixed at once in a separate patch using BUILD_BUG_ON.