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 55BE9A0544; Fri, 23 Sep 2022 12:58:03 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D1FCC40156; Fri, 23 Sep 2022 12:58:02 +0200 (CEST) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2056.outbound.protection.outlook.com [40.107.244.56]) by mails.dpdk.org (Postfix) with ESMTP id CA8564003C for ; Fri, 23 Sep 2022 12:58:01 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gDHreDlc7KcelxRu5dAUXtD33R9D7edwHvPUAxLWCHfOOpzKhUGbcNmDg+DhNj1sg6PQqzwcH1rCm4Ps4KP6DhXLSJ9ULu3+BrXzWlHlgyJqUZ0E8PxYDn2etiBJuoO3QwEOmK5QJ4O7HXD3bdFbTZJDi4LmpcwKjc2pUB2DA0iupB1eMBoEMdhmTNjwyEQXZRIeUclAzznlHzMw7cVO4cvPCZ5aYpy+gdP24JFG0aczjokm/QFIlmF3/Vf6dLahRgo36RmnxiC1ZUxGgI7o21vtd5GrIpeXIW0fwWg2l2cDjjWdMlaHtTGz9NrBu5hXSJGQFI9iikrHEW80QdA0Rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4SZs86P0uU8zLS+wimrk3PKHgw0emcubK2yl59/HN9I=; b=eS+j2EfYNhB00fVUWSJzxSlglajFqUw1FQeaXQzx6Tz5uQ6rPFpO+N5U1zHoZpk4tOjilwz1NahJGL9H4RJEbINd8ia4cbae8IKWm3OJoydW+xIon5fm19EDL/fd7hQlpIFjeuc/YC7V/dOf1TALSMmM9XZGpsR/IjC3dFJRVfDiVMLaeOMMrvRclZ57x4lWjHsL9jZuIatFiOcAOyApoNzdPcRB1giYSjaKHNakFPmFkUqrSoXAWosZotT6umsGOF32gxOf+RGkTEjKm4AoYLrDpuEdfQc5Ul9tk6CJcPrgOvcZKmp183wNDZ3+tPfvac02CpAtodNkqTNNINpvrg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 149.199.80.198) smtp.rcpttodomain=marvell.com smtp.mailfrom=amd.com; dmarc=fail (p=quarantine sp=quarantine pct=100) action=quarantine header.from=amd.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xilinx.onmicrosoft.com; s=selector2-xilinx-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4SZs86P0uU8zLS+wimrk3PKHgw0emcubK2yl59/HN9I=; b=LzNTE8K/UFGFkVf1YXrsr29r24JlTmxDlbBqbMxMXMmQkqr6pAcayqojfUGtHreFcoS8MMsZmu9FtaFHfcop/THLPtjfBiZyyZ3sgxPdezHJIKdEPwhlg0y2lgtuZm/BoGCGg7RBdgdZkRb9hFmA0za3jJx3LHZe67T2i6tvMDs= Received: from BN1PR10CA0021.namprd10.prod.outlook.com (2603:10b6:408:e0::26) by CH2PR02MB6506.namprd02.prod.outlook.com (2603:10b6:610:35::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5632.21; Fri, 23 Sep 2022 10:58:00 +0000 Received: from BN1NAM02FT004.eop-nam02.prod.protection.outlook.com (2603:10b6:408:e0:cafe::ff) by BN1PR10CA0021.outlook.office365.com (2603:10b6:408:e0::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.20 via Frontend Transport; Fri, 23 Sep 2022 10:58:00 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 149.199.80.198) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=fail action=quarantine header.from=amd.com; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning amd.com discourages use of 149.199.80.198 as permitted sender) Received: from xir-pvapexch02.xlnx.xilinx.com (149.199.80.198) by BN1NAM02FT004.mail.protection.outlook.com (10.13.2.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5654.14 via Frontend Transport; Fri, 23 Sep 2022 10:57:59 +0000 Received: from xir-pvapexch02.xlnx.xilinx.com (172.21.17.17) by xir-pvapexch02.xlnx.xilinx.com (172.21.17.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 23 Sep 2022 11:57:46 +0100 Received: from smtp.xilinx.com (172.21.105.197) by xir-pvapexch02.xlnx.xilinx.com (172.21.17.17) with Microsoft SMTP Server id 15.1.2375.24 via Frontend Transport; Fri, 23 Sep 2022 11:57:46 +0100 Envelope-to: gakhil@marvell.com, nicolas.chautru@intel.com, dev@dpdk.org, thomas@monjalon.net, hemant.agrawal@nxp.com, mdr@ashroe.eu, maxime.coquelin@redhat.com, trix@redhat.com, bruce.richardson@intel.com, david.marchand@redhat.com, stephen@networkplumber.org, mingshan.zhang@intel.com Received: from [10.71.194.74] (port=29920) by smtp.xilinx.com with esmtp (Exim 4.90) (envelope-from ) id 1obgNO-0001Ty-FU; Fri, 23 Sep 2022 11:57:46 +0100 Message-ID: <88a06267-0cf3-a6cd-0785-b5b2a419fc02@amd.com> Date: Fri, 23 Sep 2022 11:57:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: [EXT] [PATCH v7 6/7] bbdev: add queue related warning and status information Content-Language: en-US To: Akhil Goyal , Nicolas Chautru , "dev@dpdk.org" , "thomas@monjalon.net" , "hemant.agrawal@nxp.com" , Ray Kinsella CC: "maxime.coquelin@redhat.com" , "trix@redhat.com" , "bruce.richardson@intel.com" , "david.marchand@redhat.com" , "stephen@networkplumber.org" , "mingshan.zhang@intel.com" References: <1655491040-183649-6-git-send-email-nicolas.chautru@intel.com> <1661796438-204861-1-git-send-email-nicolas.chautru@intel.com> <1661796438-204861-7-git-send-email-nicolas.chautru@intel.com> From: Ferruh Yigit In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1NAM02FT004:EE_|CH2PR02MB6506:EE_ X-MS-Office365-Filtering-Correlation-Id: 3e23d88e-d490-43b1-4127-08da9d527aa9 X-MS-Exchange-SenderADCheck: 2 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: FR86t3GvIcET1cRzFDJRx8aMOQ2JbTX0tdVRM97fRxAN2jlsR0xryPizRGwr8kwCJXbPGKbDdVQvtR3itAq11s8y1kyoyXi8g6GiAsQ9vdQTbuiWwOzdUhnbvL4I0cts4aISUKwlsZwUUAi/GRLxJj2nfLBkDIeepvqYOh6Fh1I4Mt3kcLyS+3YkKGzGAiD/CDiQoIzc/f+xPpP3kZFycudfC61oO+G4iIfQ6gG1X7qaqKySs2wbFrjlTpWBhnpm3vJYvwFQ0Av/N/+0liqZi2CZgfYUYKZUtZYagGEyglPXfguWxCK1hI8vMVFjxPGcAn6bfqzfGL8HilB6yL4bMtDaJ/I4tykZBCgXP8pOnV1J9rmAL9OeERALEC8AtuDBlw9wYk4Ebqp7KnqChxm4IVPcTA4fCgb4FbIhz3I+gtfieEYm0DP9XiXQtWJrmnaLGauL79PSZ8mJnBoLSGHzpBxFnk7Q6ZfsG18KxpIM0A8L3E7BcErKDn4QhGpjN1bLIiDFVcsd0p96GWy1i6AbVY5T1aY6Z3y2mhHKJrDRvTQyIU2DRq9qtJsAO/IyjTvOpnyG0siOh95IgCtMr5kQmCUE097XSFc4VL+eONrrqa2aT4kelF8o3Uy4gjVKE086rIYRWvDseQkjFlePzUBXNqd2rCEvPsKnYtRVhjFX+zfQZEi/5M2C5yVnG98zhK/ZUEtHzZ/6qr+sFgNT4cbdJ5Bnc9a9mIOPt+ay/AO9JiPh7uAucQsQrg/HjAtAsWbM8vO+9/Yp5CbOSmWIrgjDM37oyfieaMEE7uJGB9YtKK+s7Xn1bsbcXEDpt4/lXLmNunVYGdrVkzKiu5RlGIoiUA== X-Forefront-Antispam-Report: CIP:149.199.80.198; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:xir-pvapexch02.xlnx.xilinx.com; PTR:unknown-80-198.xilinx.com; CAT:NONE; SFS:(13230022)(4636009)(136003)(346002)(376002)(396003)(39860400002)(451199015)(46966006)(40470700004)(7636003)(41300700001)(31686004)(86362001)(36756003)(82310400005)(40480700001)(82740400003)(31696002)(26005)(356005)(4326008)(9786002)(53546011)(5660300002)(70206006)(8936002)(70586007)(8676002)(44832011)(54906003)(498600001)(110136005)(316002)(83380400001)(7416002)(2906002)(2616005)(47076005)(336012)(40460700003)(35950700001)(50156003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: xilinx.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2022 10:57:59.5419 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3e23d88e-d490-43b1-4127-08da9d527aa9 X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c; Ip=[149.199.80.198]; Helo=[xir-pvapexch02.xlnx.xilinx.com] X-MS-Exchange-CrossTenant-AuthSource: BN1NAM02FT004.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR02MB6506 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 On 9/21/2022 8:21 PM, Akhil Goyal wrote: >> diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h >> index ed528b8..b7ecf94 100644 >> --- a/lib/bbdev/rte_bbdev.h >> +++ b/lib/bbdev/rte_bbdev.h >> @@ -224,6 +224,19 @@ struct rte_bbdev_queue_conf { >> rte_bbdev_queue_stop(uint16_t dev_id, uint16_t queue_id); >> >> /** >> + * Flags indicate the reason why a previous enqueue may not have >> + * consumed all requested operations >> + * In case of multiple reasons the latter superdes a previous one > Spell check - supersedes. > >> + */ >> +enum rte_bbdev_enqueue_status { >> + RTE_BBDEV_ENQ_STATUS_NONE, /**< Nothing to report */ >> + RTE_BBDEV_ENQ_STATUS_QUEUE_FULL, /**< Not enough room in >> queue */ >> + RTE_BBDEV_ENQ_STATUS_RING_FULL, /**< Not enough room in >> ring */ >> + RTE_BBDEV_ENQ_STATUS_INVALID_OP, /**< Operation was >> rejected as invalid */ >> + RTE_BBDEV_ENQ_STATUS_PADDED_MAX = 6, /**< Maximum enq >> status number including padding */ > > Are we ok to have this kind of padding across DPDK for all the enums to avoid ABI issues? > @Ray, @Thomas: any thoughts? > > This kind of usage can prevent ABI tool warning, and can fix issues caused by application using returned enum as index [1]. But I think it is still problematic in case application tries to walk through till MAX, that is a common usage [2], user may miss that this is PADDED. Overall exchanging enum values between library and application is possible trouble for binary compatibility. If application and library uses enum values independently, this is OK. Since enum cases not deleted but added in new version of the libraries, more problematic usage is passing enum value from library to application, and bbdev seems doing this in a few places. With current approach PADDED_MAX usage is more like #define usage, it is not dynamic but a hardcoded value that is used as array size value. Not providing a MAX enum case restricts the application, application can't use it as size of an array or can't use it walk through related array, usage reduces to if/switch comparisons. Although this may not be most convenient for application, it can provide safer usage for binary compatibility. @Nic, what do you think provide these PADDED_MAX as #define SIZE_MAX macros? With this application still can allocate a relevant array with correct size, or know the size of library provided array, but can't use it to iterate on these arrays. [1] --------------- library old version ---------------------------- enum type { CASE_A, CASE_B, CASE_MAX, }; struct data { enum type type; union { type specific struct }; }; int api_get(struct data *data); --------------- application ---------------------------- struct data data; int array[CASE_MAX]; api_get(&data); foo(array[data.type]); --------------- library NEW version ---------------------------- enum type { CASE_A, CASE_B, CASE_C, CASE_D, CASE_MAX, }; When application is NOT recompiled but using new version of the library, values 'CASE_C' & 'CASE_D' will crash application, so this will create a ABI compatibility issue. Note: In the past I have claimed that application should check 'CASE_MAX', instead of using returned value directly as index, but this is refused by argument that we can't control the application and should play safe assuming application behaves wrong. [2] --------------- library ---------------------------- enum type { CASE_NONE, CASE_A, CASE_B, CASE_C, CASE_D, CASE_PADDED_MAX = 666, }; --------------- application ---------------------------- for (int i = CASE_NONE; i < CASE_PADDED_MAX; i++) fragile_init(i); ---