From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3ECBDA0565; Tue, 17 Mar 2020 16:10:35 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 22DC625D9; Tue, 17 Mar 2020 16:10:34 +0100 (CET) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id EC970CF3 for ; Tue, 17 Mar 2020 16:10:31 +0100 (CET) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 1ECF95804C9; Tue, 17 Mar 2020 11:10:31 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 17 Mar 2020 11:10:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=idk0cVioVSf1/PnBYshCizES05brF/nSZFlANYBK9rU=; b=TLpyr/e7uWaf 7T2ggjGEGJfvTY4Rs1FBy1MkL19bfo720SJRak6zp8cT7Gy2UHXGNR7XZMDIZW4y P9EBD+hLShVKGBndbE0BcQyclonsboddBCHfWJ73O0b6qV+fNsNQc+E9bPxCZR3J 21S1u2Nmd/L6EbX2cwtUFIYjg/GEHSg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=idk0cVioVSf1/PnBYshCizES05brF/nSZFlANYBK9 rU=; b=AluRNZVXzYutHqUq+SZqs/aZltrA7Mbbx9Py8ABNTcMIC3Qrccr+tNl/1 xzUez0bIA7rlCs2wp/DI6E5Gx0eVmqkv4MsN3z0yjlI9B6ILcVnt0zDx8VSpTi+Q gWp4UsEWBvaV8Bp/8Kp+sZnJpAWLHOtt+84qSheRSJ3dt2e8bC0ZzE7jnRDEzUJU 1HC/L/iiAHnvxoCAG/jM9P7xeKoWqdf089klw9jQ1oIqXDsz0c8JKgilPrMr+NZa wPMm8YyfouI1VYmNs+r+CGX88UHhNBQ0DG/p6LQp2R/HfvJkBRaU9Gk/rqLJ0cpZ 4tCWEP/AZzpSA1U/r6SH/LX8j0rOA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudefhedgieekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 8084130618C1; Tue, 17 Mar 2020 11:10:23 -0400 (EDT) From: Thomas Monjalon To: "Trahe, Fiona" , "Kusztal, ArkadiuszX" Cc: David Marchand , "nhorman@tuxdriver.com" , "bluca@debian.org" , "ktraynor@redhat.com" , Ray Kinsella , "dev@dpdk.org" , Akhil Goyal , "Yigit, Ferruh" , "Ananyev, Konstantin" , "dev@dpdk.org" , Anoob Joseph , "Richardson, Bruce" , "Mcnamara, John" , "dodji@seketeli.net" , Andrew Rybchenko , "aconole@redhat.com" , "Trahe, Fiona" Date: Tue, 17 Mar 2020 16:10:20 +0100 Message-ID: <56588879.matp6XCIr4@xps> In-Reply-To: References: <20191220152058.10739-1-david.marchand@redhat.com> <2810256.WAvfycf1tz@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 4/4] add ABI checks X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 17/03/2020 14:27, Kusztal, ArkadiuszX: > Hi Thomas, > > > -----Original Message----- > > From: Thomas Monjalon > > Sent: Monday, March 16, 2020 2:09 PM > > To: Trahe, Fiona > > Cc: Kusztal, ArkadiuszX ; David Marchand > > ; nhorman@tuxdriver.com; > > bluca@debian.org; ktraynor@redhat.com; Ray Kinsella ; > > dev@dpdk.org; Akhil Goyal ; Yigit, Ferruh > > ; Ananyev, Konstantin > > ; dev@dpdk.org; Anoob Joseph > > ; Richardson, Bruce ; > > Mcnamara, John ; dodji@seketeli.net; Andrew > > Rybchenko ; aconole@redhat.com; Trahe, > > Fiona > > Subject: Re: [dpdk-dev] [PATCH v2 4/4] add ABI checks > > > > 16/03/2020 13:57, Trahe, Fiona: > > > From: Kusztal, ArkadiuszX > > > > > > > The patch we're working on will provide two versions of > > > > > > > rte_cryptodev_info_get(), both call the same PMD function from > > > > > > > the > > > > > dev_ops info_get fn ptr. > > > > > > > The default version operates s as normal, the 19.11 version > > > > > > > searches through the list returned by the PMD, looking for > > > > > > > sym.aead.algo = ChaChaPoly, it needs to strip it from > > > > > > the list. > > > > > > > As PMDs just pass a ptr to their capabilities list ( it isn't > > > > > > > a linked list, but an array with an end marker = > > > > > > > RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST) if the API layer > > > > > > > detects Chacha it must allocate some space and store a local > > > > > > > copy of the trimmed > > > > > list. This must be stored only once per device. > > > > > > > > [Arek] The problem with this solution is that we need to allocate memory. > > > > So the question is how to handle unlikely case of malloc error when > > > > we operate inside void function rte_cryptodev_info_get? > > > > And even if we would pass somehow error condition to the caller then > > what to do is another question. > > > > > > [Fiona] Quick recap: To avoid breaking ABI, we must return a set of > > > capabilities with/without ChaChaPoly depending on the appl version. To > > > resolve this, within the rte_cryptodev layer, we propose to inspect the > > capabilities returned by PMD and strip ChaCha if it exists. > > > In that case memory for the new trimmed capabilities array has to be > > malloced by the lib. > > > > What happens if the capability is removed from the original capabilities > > input? > > > > > All good, except how to handle a malloc fail is yet another API breakage as > > rte_cryptodev_get_info() returns void. > > > We propose to return an empty capability list, i.e. a list with only > > > the END element (which can be done without malloc) in this corner case of > > a corner case. > > > Anyone see any issue with this? > > > > How can we use the feature if it is not advertised in capabilities? > What Fiona meant is that empty capability would indicate error condition in this case. That's why she asked if you ok with this API breakage. Sorry I'm lost. Please could you show what would be the usage?