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 950C0A04DD; Wed, 28 Oct 2020 16:12:00 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E2082CBAB; Wed, 28 Oct 2020 16:11:57 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 56472CB93; Wed, 28 Oct 2020 16:11:53 +0100 (CET) IronPort-SDR: MZgs+JEUSQ/G2C3WToATX4arskqO7Crerfd7xZ4vmkigoCvjZAMMrHyBRg8T+FyL/Qb3HAdORK sMmr3hWX3A1w== X-IronPort-AV: E=McAfee;i="6000,8403,9788"; a="168372032" X-IronPort-AV: E=Sophos;i="5.77,426,1596524400"; d="scan'208";a="168372032" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Oct 2020 08:11:39 -0700 IronPort-SDR: By1VpAkukiwtkFK2f+UUERhr184mj6ByitfSqLfQs2e8QHhQcGd/Y5jsvbs81eFdjsq0rpOjCN kfmUisvRiQWQ== X-IronPort-AV: E=Sophos;i="5.77,426,1596524400"; d="scan'208";a="536263090" Received: from bricha3-mobl.ger.corp.intel.com ([10.255.205.158]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 28 Oct 2020 08:11:35 -0700 Date: Wed, 28 Oct 2020 15:11:30 +0000 From: Bruce Richardson To: Akhil Goyal Cc: "Ananyev, Konstantin" , "Gujjar, Abhinandan S" , "dev@dpdk.org" , "Doherty, Declan" , "Honnappa.Nagarahalli@arm.com" , "techboard@dpdk.org" , "Vangati, Narender" , "jerinj@marvell.com" Message-ID: <20201028151130.GD1634@bricha3-MOBL.ger.corp.intel.com> References: <1603619090-118652-1-git-send-email-abhinandan.gujjar@intel.com> <1603619090-118652-2-git-send-email-abhinandan.gujjar@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [dpdk-techboard] [v4 1/3] cryptodev: support enqueue callback functions 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" On Wed, Oct 28, 2020 at 02:28:43PM +0000, Akhil Goyal wrote: > > Hi Konstantin, > > > > > Hi Tech board members, > > > > > > > > I have a doubt about the ABI breakage in below addition of field. > > > > Could you please comment. > > > > > > > > > /** The data structure associated with each crypto device. */ struct > > > > > rte_cryptodev { > > > > > dequeue_pkt_burst_t dequeue_burst; > > > > > @@ -867,6 +922,10 @@ struct rte_cryptodev { > > > > > __extension__ > > > > > uint8_t attached : 1; > > > > > /**< Flag indicating the device is attached */ > > > > > + > > > > > + struct rte_cryptodev_enq_cb_rcu *enq_cbs; > > > > > + /**< User application callback for pre enqueue processing */ > > > > > + > > > > > } __rte_cache_aligned; > > > > > > > > Here rte_cryptodevs is defined in stable API list in map file which is a pointer > > > > To all rte_cryptodev and the above change is changing the size of the > > structure. > > > > While this patch adds new fields into rte_cryptodev structure, > > it doesn't change the size of it. > > struct rte_cryptodev is cache line aligned, so it's current size: > > 128B for 64-bit systems, and 64B(/128B) for 32-bit systems. > > So for 64-bit we have 47B implicitly reserved, and for 32-bit we have 19B > > reserved. > > That's enough to add two pointers without changing size of this struct. > > > > The structure is cache aligned, and if the cache line size in 32Byte and the compilation > is done on 64bit machine, then we will be left with 15Bytes which is not sufficient for 2 > pointers. > Do we have such systems? Am I missing something? > I don't think we support any such systems, so unless someone can point out a specific case where we need to support 32-byte CLs, I'd tend towards ignoring this as a non-issue. > The reason I brought this into techboard is to have a consensus on such change > As rte_cryptodev is a very popular and stable structure. Any changes to it may > Have impacts which one person cannot judge all use cases. > Haven't been tracking this discussion much, but from what I read here, this doesn't look like an ABI break and should be ok. Regards, /Bruce