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 F2776A00BE; Thu, 17 Feb 2022 15:34:24 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 59CD240150; Thu, 17 Feb 2022 15:34:24 +0100 (CET) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by mails.dpdk.org (Postfix) with ESMTP id C14FE40042 for ; Thu, 17 Feb 2022 15:34:22 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id EEEC758050D; Thu, 17 Feb 2022 09:34:21 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 17 Feb 2022 09:34:21 -0500 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; bh=5zwvsAYMwYK7cQ uKd0ivRugZOaWhPpG0JOUnCvL6HMQ=; b=dZnF1b+PM9BaHDvWGq61ogxvJVa6iy H79fCoH5dN2bu2vegseyj2Z1KmNS2IieJyQiK0nVPEXJeWI4gyCHR1frvHmbJhKZ e/ckFZ2E61zR6t4gvyF93iUGM4UJvtguGjKOZsdfpbGej6cO0Elevj4ZGwET8TS1 FiemSeianDfF9gNQfpd7VMkRj/DFycMT/sn0o2xvFu+dZLZsGEEsIRzshWiMXVAI xTooxfR3TiIIR2bIvYpacbih8JwK2h1LuvjimElCVMvdy3K1wbJoBf65DBzAZdiJ xtqpi0cOUop7hoXly63QUgzlkQ8hoswBlfnXslC1kFrF3AWI8ZqvQeyQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=5zwvsAYMwYK7cQuKd0ivRugZOaWhPpG0JOUnCvL6H MQ=; b=M3v8LyltdZGEl5Y0I/o9waXpeFHzXw9XVEXwkhGsva9mQLUoYeOcETB9l 16znWNG7xXA4ECiy1coDT+EAPy+w3PSOCEyQlKBs2mdY5K5OkE2NBT0Q+XYplJlT TOueQZoI9ln3SUjN3AkVxMj0OWcXMjTW3oIgusUWYTpJdCy7VYq7081L90i3Pbrk YaanhxJh4Hert5cOhAy01e/njzdmaUO9KC5EcLWaApeqJlktziiR7pjclx7bdNNz P6KJCDk9QxqTJQZzVAhwsXk+USU/sMc0GkESXrPWPedEgTcauP5cPmJ9vnfNIxiE S355Xd5PygPyKYiO1FfHJZURGzPsQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrjeekgdeihecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 17 Feb 2022 09:34:19 -0500 (EST) From: Thomas Monjalon To: Andrew Rybchenko , Alexander Kozyrev , "dev@dpdk.org" , Ori Kam Cc: "ivan.malov@oktetlabs.ru" , "ferruh.yigit@intel.com" , "mohammad.abdul.awal@intel.com" , "qi.z.zhang@intel.com" , "jerinj@marvell.com" , "ajit.khaparde@broadcom.com" , "bruce.richardson@intel.com" Subject: Re: [PATCH v5 03/10] ethdev: bring in async queue-based flow rules operations Date: Thu, 17 Feb 2022 15:34:17 +0100 Message-ID: <6856670.dE46n4Xy2H@thomas> In-Reply-To: References: <20220209213809.1208269-1-akozyrev@nvidia.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 17/02/2022 15:16, Ori Kam: > From: Ori Kam > > From: Andrew Rybchenko > > > On 2/16/22 17:53, Ori Kam wrote: > > > > From: Andrew Rybchenko > > > >> On 2/12/22 05:19, Alexander Kozyrev wrote: > > > >>> On Fri, Feb 11, 2022 7:42 Andrew Rybchenko : > > > >>>>> +/** > > > >>>>> + * @warning > > > >>>>> + * @b EXPERIMENTAL: this API may change without prior notice. > > > >>>>> + * > > > >>>>> + * Queue operation attributes. > > > >>>>> + */ > > > >>>>> +struct rte_flow_q_ops_attr { > > > >>>>> + /** > > > >>>>> + * The user data that will be returned on the completion events. > > > >>>>> + */ > > > >>>>> + void *user_data; > > > >>>> > > > >>>> IMHO it must not be hiddne in attrs. It is a key information > > > >>>> which is used to understand the opration result. It should > > > >>>> be passed separately. > > > >>> > > > >>> Maybe, on the other hand it is optional and may not be needed by an application. > > > >> > > > >> I don't understand how it is possible. Without it application > > > >> don't know fate of its requests. > > > >> > > > > IMHO since user_data should be in all related operations API > > > > along with the attr, splitting the user_data will just add extra parameter > > > > to each function call. Since we have number of functions and will add > > > > more in future I think it will be best to keep it in this location. > > > > > > My problem with hiding user_data inside attr is that > > > 'user_data' is not an auxiliary attribute defining extra > > > properties of the request. It is a key information. > > > May be attr is not an ideal name for such grouping > > > of parameters. Unfortunately I have no better ideas right now. > > > > > I understand your point, if you don't have objections lets keep the current one > > and if needed we will modify. > > Is that O.K? > > Thinking about it again, > lets move it to a dedecated parameter. I'm OK with the decision of moving user_data as a function parameter.