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 37AE2A0543; Mon, 13 Jun 2022 20:35:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2374840223; Mon, 13 Jun 2022 20:35:55 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id 82CCD40222 for ; Mon, 13 Jun 2022 20:35:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1655145353; x=1686681353; h=from:to:cc:subject:date:message-id; bh=fLlJjujJLov2A2/JmCLbSNlNNKBOBK7qcPaQOsyZcr0=; b=BYDOLNpTV9WO7o8HK+8TUshcIsUalOmQ0k5vXOpKwe6dUTW4Xu68AU1X CHAMVqTwUE7og18ljb5lw7e5vgs06qkG2S1wdKZfX9FetW9Uc28UikMMb Qrq+h/vkv7ySbAb9GmABUXEcYRqm0tzsqwh2djhm8G3KfkLk8Z8tdawBW amRVtta4Ug9judWQSMNFrkZ89pqih4C4TI/L0VDNASuWNZWmwOVxX8r3o FjvYe8E07fR7JCBw7O51D9AaX+txBBO79V2UhMHuRg0XabY0iXNOlRe2Y Noxg/VQ6n5/ZQm6hTZOMsRgihXXVVTApSuo0mS0CHrR/vC7zjpW40CpH4 g==; X-IronPort-AV: E=McAfee;i="6400,9594,10377"; a="278408408" X-IronPort-AV: E=Sophos;i="5.91,297,1647327600"; d="scan'208";a="278408408" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jun 2022 11:35:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,297,1647327600"; d="scan'208";a="726392684" Received: from skx-5gnr-sc12-4.sc.intel.com ([172.25.69.210]) by fmsmga001.fm.intel.com with ESMTP; 13 Jun 2022 11:35:52 -0700 From: Nicolas Chautru To: dev@dpdk.org, thomas@monjalon.net Cc: maxime.coquelin@redhat.com, trix@redhat.com, mdr@ashroe.eu, bruce.richardson@intel.com, hemant.agrawal@nxp.com, david.marchand@redhat.com, stephen@networkplumber.org, Nicolas Chautru Subject: [PATCH v1] bbdev: allow operation type enum for growth Date: Mon, 13 Jun 2022 11:24:34 -0700 Message-Id: <1655144675-14363-1-git-send-email-nicolas.chautru@intel.com> X-Mailer: git-send-email 1.8.3.1 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 Hi Thomas, I would like to get your view on this topic and best recommendation moving forward. This is related to the general intent to remove using MAX value for enums. There is consensus that we should avoid this for a while notably for future-proofed ABI concerns https://patches.dpdk.org/project/dpdk/patch/20200130142003.2645765-1-ferruh.yigit@intel.com/. But still there is arguably not yet an explicit best recommendation to handle this especially when we actualy need to expose array whose index is such an enum. As a specific example here I am refering to RTE_BBDEV_OP_TYPE_COUNT in enum rte_bbdev_op_type which is being extended for new operation type being support in bbdev (such as https://patches.dpdk.org/project/dpdk/patch/1646956157-245769-2-git-send-email-nicolas.chautru@intel.com/ adding new FFT operation) There is also the intent to be able to expose information for each operation type through the bbdev api such as dynamically configured queues information per such operation type https://patches.dpdk.org/project/dpdk/patch/1646785355-168133-2-git-send-email-nicolas.chautru@intel.com/ Basically we are considering best way to accomodate for this, notably based on discussions with Ray Kinsella and Bruce Richardson, to handle such a case moving forward: specifically for the example with RTE_BBDEV_OP_TYPE_COUNT and also more generally. One possible option is captured in that patchset and is basically based on the simple principle to allow for growth and prevent ABI breakage. Ie. the last value of the enum is set with a higher value than required so that to allow insertion of new enum outside of the major ABI versions. In that case the RTE_BBDEV_OP_TYPE_COUNT is still present and can be exposed and used while still allowing for addition thanks to the implicit padding-like room. As an alternate variant, instead of using that last enum value, that extended size could be exposed as an #define outside of the enum but would be fundamentally the same (public). Another option would be to avoid array alltogether and use each time this a new dedicated API function (operation type enum being an input argument instead of an index to an array in an existing structure so that to get access to structure related to a given operation type enum) but that is arguably not well scalable within DPDK to use such a scheme for each enums and keep an uncluttered and clean API. In that very example that would be very odd indeed not to get this simply from info_get(). Some pros and cons, arguably the simple option in that patchset is a valid compromise option and a step in the right direction but we would like to know your view wrt best recommendation, or any other thought. Note: Such a change is aimed for 22.11. Thanks and regards, Nic Nicolas Chautru (1): bbdev: allow operation type enum for growth lib/bbdev/rte_bbdev.c | 5 ++++- lib/bbdev/rte_bbdev_op.h | 2 +- 2 files changed, 5 insertions(+), 2 deletions(-) -- 1.8.3.1