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 82139A0559; Mon, 16 Mar 2020 14:09:18 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8B48B1AFF; Mon, 16 Mar 2020 14:09:17 +0100 (CET) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id BEC88FEB for ; Mon, 16 Mar 2020 14:09:15 +0100 (CET) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 082995805C3; Mon, 16 Mar 2020 09:09:14 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 16 Mar 2020 09:09:14 -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=SR/76PE47LAFJg6AFasn/MRVl2a6kYbAJOpjTvAB9lA=; b=bjkqhUcTEbef jE60NjNbS5RzrJVS3giAJXFVgbDddjwMGRQe9uR47ICbFaE+NZ/Ii9XCJxTg8ro1 RqCzfu+M3C/nzLbZKkW5kHqWcsFiGgtQhgob4SUrr7QJdsyeqqeFTKeotfwcgXSG u2F3lRYHwpeEeWZiILBQ1jZ0adZ4/n8= 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=SR/76PE47LAFJg6AFasn/MRVl2a6kYbAJOpjTvAB9 lA=; b=FAfxrQVS0kZfih3o0iQzVQ2a43Pfys6Js9zrPgwnE6OEK/Gq4Z9Z20DNA 5TzaJBBeqXB9EBnxPxg+NuVA2dPHk2bEWcduh9vZEpumVgFngEuT1zpxhFfoxEEY EqJP/jEkVyw9mPsBNTLpL8tomQOcHFsZw0PgmFhfR9t1tve6DlSqJ8KrkrcV4fC7 ASgTyr3pRgP7MTfLGxzuBfkvLNb82ewblsuhSE3hj462tIT+KyiK5IIMylmSXrOu oPaKZTiusN+AFTJVX2kQt5rOHnWSMFDuBP2RdMmIHg2NhweZ4Qk0Rbbpbj3cVCgs sUzD5Sk0YdKEOoK2AF/wuHJHbKJtQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeffedggeekucetufdoteggodetrfdotf 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 A64123280064; Mon, 16 Mar 2020 09:09:09 -0400 (EDT) From: Thomas Monjalon 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" Date: Mon, 16 Mar 2020 14:09:08 +0100 Message-ID: <2810256.WAvfycf1tz@xps> In-Reply-To: References: <20191220152058.10739-1-david.marchand@redhat.com> 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" 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?