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 64D29A04FD; Sun, 17 Jul 2022 12:46:42 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0401140695; Sun, 17 Jul 2022 12:46:42 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id CE05F40687 for ; Sun, 17 Jul 2022 12:46:39 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 720355C010C; Sun, 17 Jul 2022 06:46:39 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sun, 17 Jul 2022 06:46:39 -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=fm3; t=1658054799; x= 1658141199; bh=ebiQ3JO2YjjM+JpEpd0MPwcRQWwTv0QxqY4mF+4ooPM=; b=T AQVDiYTlws9p5ws+2ffMnMQZTcNQvj7b54VViBOE28LB7nGhcdT5tpWXFQMy+TIc f4QWJAlhdd9IHjHo6T6W5AFllFNl/UNt2dQu20GFbcGzjZ6dJTkdRXkdHuZbsT/A H80z8s6n6jEyWy+fQS8Z1sHVNM91+EQEF2/fLC2RthRJ7Ly/pDW2ynDPxWkr8bqL xceF7zgJkHLu3bNUVYTUr/yljfP7ZtaLV9qDsdPgsyQhznXu94d/6hJHtUrLuWSn Pw8booxmSGe27blKJjqmOZPzLrYuSZRnMUa72fxsFCbHc88Xb0crwyZelYqUtH80 wku7/9y3L6sjrMweb5wqA== 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=fm3; t=1658054799; x= 1658141199; bh=ebiQ3JO2YjjM+JpEpd0MPwcRQWwTv0QxqY4mF+4ooPM=; b=n UkvMbN4p/RtMx9LiSAKQVnGrCmitia22W9GL8fcSKe//9NO+9ZGQgETdr0Ah3Iba RLMRZKO4lMK12Ub7hG08PPptMkqQ9OkA235kJ4ft6OPaEoUmaFz01sfZrn7V2A4f y0weP1tszPwn+LjwiIDoQowS0q+1f3bagbb0Xi8Ep+c8cAf6pb8Fto1nCZRwUzbe nz+mvIBfToRVL0mSflNwtWNaRI0LHPJDbT2HW5sl2AIm8VD7IyJusIyG/2ChMuiZ OsRmc1zdjOo+duY4iFK7mGTzgxgWRIM09bGmEsmmq7+r0dXxa1ZoWpa/byripxw0 q7UbHTnSPRRfLh6YzQ4Uw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudekiedgfedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeejjefffffgffekfefflefgkeelteejffelledugefhheelffet heevudffudfgvdenucffohhmrghinhepughpughkrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 17 Jul 2022 06:46:37 -0400 (EDT) From: Thomas Monjalon To: gakhil@marvell.com, Srujana Challa Cc: roy.fan.zhang@intel.com, dev@dpdk.org, jerinj@marvell.com, ndabilpuram@marvell.com, anoobj@marvell.com, david.marchand@redhat.com, bruce.richardson@intel.com, konstantin.v.ananyev@yandex.ru, matan@nvidia.com, honnappa.nagarahalli@arm.com Subject: Re: [RFC PATCH] cryptodev: add return parameter to callback process API Date: Sun, 17 Jul 2022 12:46:36 +0200 Message-ID: <2989100.CbtlEUcBR6@thomas> In-Reply-To: <20220624121217.3450612-1-schalla@marvell.com> References: <20220624121217.3450612-1-schalla@marvell.com> 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 24/06/2022 14:12, Srujana Challa: > Adds a return parameter "uint16_t qp_id" to the functions > rte_cryptodev_pmd_callback_process and rte_cryptodev_cb_fn. > The new parameter is used to return queue pair ID to > the application when it gets error interrupt, so that > application can disable and enable the queue pair, to bring > the queue back to normal state. What about other events? > + * @param qp_id Return parameter from driver to the application. Driver > + * returns queue pair ID when it gets HW error interrupt. > + * The application can release and setup the queue > + * again, to bring the HW queue back to normal state. What will it mean if the event is not related to queues? > * @param event Crypto device event to register for notification of. > * @param cb_arg User specified parameter to be passed as to passed to > * users callback function. Are you going to add a new callback parameter each time the application needs info about a new event? In my opinion, it is a very bad idea. As done in ethdev, you should add a query function specific to the event. Example: https://git.dpdk.org/dpdk/commit/?id=bc70e5594838 Here, when a threshold is reached, an event RTE_ETH_EVENT_RX_AVAIL_THRESH is fired, and the application can get more info about what happened by calling the function rte_eth_rx_avail_thresh_query(). Look at the parameters description: " @param[inout] queue_id On input starting Rx queue index to search from. If the queue_id is bigger than maximum queue ID of the port, search is started from 0. So that application can keep calling this function to handle all pending events with a simple increment of queue_id on the next call. On output if return value is 1, Rx queue index with the event pending. @param[out] avail_thresh Location for available descriptors threshold of the found Rx queue. "