From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 41DD5A04FD; Mon, 3 Oct 2022 19:22:07 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DC00440DFB; Mon, 3 Oct 2022 19:22:06 +0200 (CEST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by mails.dpdk.org (Postfix) with ESMTP id C1F0540695 for ; Mon, 3 Oct 2022 19:22:05 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id B1B493200904; Mon, 3 Oct 2022 13:22:02 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 03 Oct 2022 13:22:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1664817722; x= 1664904122; bh=L0SHosapSvlv5t0J/bWTR0OR9mMQnStZA4lUfy17K5E=; b=v cu1GOQFt17asPeQcnKIlLxcNmg9vZ0KRlbWnW5VV/XFJy6WSHq+7H16gyGwMAIYk ebiysemhr+CvDmBGbmWW4PEUSwA70JAIUF4uxZ2dmXdzlnYR/80bQyxDGmHx2Kq8 kmYN4He/ZTGiTCOhofSodFONky2/qu3G8kFfE400cwOsn13Cul2SwdtHwkKSox/r MJjbRiAuNSr/wCZwCC5BHC4PIg9Oj42QYHe/yt14jx2c7JNOBDxPjgOQ8oIaBycP bQIFt3kCWAofY4uLR4XaVhnhjyQIqClQh6YbBQ8ABcsOH21SxhgpD7s0JbOZ7GiE 7FNLQzUwBXQH/qvwlNIdQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1664817722; x= 1664904122; bh=L0SHosapSvlv5t0J/bWTR0OR9mMQnStZA4lUfy17K5E=; b=H XK7D3rCatCL6q3MBRrtHnWVT9R5GytNF4qHbiIIx76IaU9ZO6pXur0R7XkDn8CO0 d+Kmj+L4vkajAm0w6Qd+utXVDNIOn1txRJD4Br/yMaufrnN0tOuXrvgxBG73MQ2p O3TaVs5sgKK3LLzmCO2VpNEEw1z3DC+BfNXZyM9BqI+TAGIKSsNBI5BCUhuWciZW o9SSOFvJhzOcHuSNe5cewBRh/gRZac5VUMo5e7q87CtXYERYC1fnFz4pMFf2dnCH k+SJZ37BUZE1xOTzhn+SQOqsUGgGloMnkhLQuiWNWAvB5tXgeFT93rj9Si3JQAbV OYDT/RIn6ve9h0DPPMRxw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeehledguddutdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhho mhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqne cuggftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddt ieekgfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 3 Oct 2022 13:22:00 -0400 (EDT) From: Thomas Monjalon To: "Chautru, Nicolas" Cc: "dev@dpdk.org" , "gakhil@marvell.com" , "maxime.coquelin@redhat.com" , "trix@redhat.com" , "mdr@ashroe.eu" , "Richardson, Bruce" , "david.marchand@redhat.com" , "stephen@networkplumber.org" , "Zhang, Mingshan" , "hemant.agrawal@nxp.com" Subject: Re: [PATCH v10 6/7] bbdev: add queue related warning and status information Date: Mon, 03 Oct 2022 19:21:59 +0200 Message-ID: <10152654.qUNvkh4Gvn@thomas> In-Reply-To: References: <1655491040-183649-6-git-send-email-nicolas.chautru@intel.com> <3072887.zE8UqtGg2D@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 03/10/2022 18:39, Chautru, Nicolas: > Hi Thomas, > > I will update all your comments below today, thanks. Please do a self review of other patches (I reviewed only this one), I suspect there are a lot of other details to improve in other places. > The one where we need your confirmation is specifically this comment from your, I believe we discussed but good to make sure we are all aligned: Yes let's be clear. > > But the big question is why do we need this "MAX" value? > > The guideline is to avoid using such MAX value for long term compatibility. > > This is not a _MAX enum but a _SIZE_MAX for array related to that enum. Note that the actual max value of the enum exists but is used a private macro. > The distinction is that the application cannot make any assumptions on what is the maximum enum value (ie. we don't want enum with MAX value, that is not future proof has captured in doc). > But the application can make some assumption on the sizing of array based on such an enum. The difference being the padding which allows for the enum growth without breaking ABI or application. > The previous name was _PADDED_MAX to make it clear this not a max enum but a padded value. Then more recenrtly the consensus in the community was to change this to _SIZE_MAX to be arguably more explicit this is to be used for array size. The comments I believe also make it clear this is not a MAX enum. > > Does that make sense and do you agree this is best consensus so far to move forward? It makes a lot of sense to me because this is what I proposed 2 or 3 years ago to the techboard when we approached different general solutions. But it has been said that it is not ideal for 2 reasons I think: - there is a compatibility breakage when we reach the maximum - there is no assumption on how the padding is filled That's why the preferred way should be to avoid having any maximum value. For instance, array allocation and iteration could be done in the API. Anyway I'm fine with your solution for now.