From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E96A1A04DC; Mon, 26 Oct 2020 13:34:27 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C59432B9D; Mon, 26 Oct 2020 13:34:26 +0100 (CET) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 138D1100C for ; Mon, 26 Oct 2020 13:34:24 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id BBD375C0163; Mon, 26 Oct 2020 08:34:23 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 26 Oct 2020 08:34:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= C6ehDdzQ49Uo7vrH0QhDgVuMhKJ3qSauinbKDVp17to=; b=IRozZQvrX9pejrxR jBiEUKAh1ud9lc+v56uPJ0IhAC7hhn3nr1gOtdstkE5J//Uodt2H9HEfdRCeVYBc pPrknOvzZcrVjfJRvzBYuL8TGEouuepI9s+EEmycYXOoGvjHMjbSHvV/+5mir6/9 0PRRX60oMXU5ImAvWAic5UVEK0A+NS/f4yn8e5QjG/HdjJLG64GJJP6fHSE3fcRT 8h8HnK2X9yT28u4X3hwkC8C89eHSHoW+3VqTxmgudsXjoVwTPhwKwq0xj5O/LI1R 7Fj5srI9J2YT9ZVb/Pr23507eUn3LW8MSh31GjOCQTzLcS4PNE+8IDmd1wgcM3G+ 0PFW3w== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=C6ehDdzQ49Uo7vrH0QhDgVuMhKJ3qSauinbKDVp17 to=; b=ZhRafZb65Orv2pBRZcj1JdJnkZcQIdcKvvMJ6VcqggET7PG5oybf2CryR aR5uZw36XaQrSXng7499kZC8Q4mD+B0zQtXuDoT+PMvNzHGlng6ipF8pKj414OKz AYy/KxGlV7+Gsrhs9lZhaPFnmLejCsyjzVLenhemGHIIuKfF103wbryzcbpUWlKH IP8vtoYAe9krovUzAOz6Oray9Z8+p01c0HH0KNysXgoPOXuB0tz1JFs+4kPzdXRe bL6oGd+AKDuV+vDt9RTTDiZCxvkBZ+R0iT9VLcZlm7YWRFjQVf97q0wm0VRVwal7 +k6qlgikLm2PFvH+gQ5pXB65ArcMA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrkeejgddtgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 88D203064610; Mon, 26 Oct 2020 08:34:21 -0400 (EDT) From: Thomas Monjalon To: Andrew Rybchenko Cc: Yunjian Wang , dev@dpdk.org, ferruh.yigit@intel.com, jerry.lilijun@huawei.com, xudingke@huawei.com, matan@nvidia.com Date: Mon, 26 Oct 2020 13:34:19 +0100 Message-ID: <3765724.HKehNzLIeC@thomas> In-Reply-To: <805008d1-0e44-3cae-4997-80afacb79bd6@oktetlabs.ru> References: <2394739.RyDTFpqa36@thomas> <805008d1-0e44-3cae-4997-80afacb79bd6@oktetlabs.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] ethdev: fix data type for port id 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 26/10/2020 13:33, Andrew Rybchenko: > On 10/26/20 3:29 PM, Thomas Monjalon wrote: > > 26/10/2020 13:24, wangyunjian: > >> From: Yunjian Wang > >> > >> The ethdev port id should be 16 bits now. This patch fixes the data > >> type of the variable for 'pid', changing from uint32_t to uint16_t. > >> > >> Fixes: 5b7ba31148a8 ("ethdev: add port ownership") > > > > It was 32-bit on purpose, to avoid overflow in this loop: > > for (pid = 0; pid < RTE_MAX_ETHPORTS; pid++) > > > > It is now replaced by RTE_ETH_FOREACH_VALID_DEV, > > but I wonder whether we still have this theoritical overflow risk. > > If yes, we should change more variables to 32-bit. > > Ah, it is too tricky. May be it is better to ensure that > RTE_MAX_ETHPORTS is less or equal to UINT16_MAX? Yes could be another option.