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 F0617A0524; Wed, 14 Apr 2021 10:18:57 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D47101617E7; Wed, 14 Apr 2021 10:18:57 +0200 (CEST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by mails.dpdk.org (Postfix) with ESMTP id 3C41B1617D9 for ; Wed, 14 Apr 2021 10:18:56 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id D94A558064E; Wed, 14 Apr 2021 04:18:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 14 Apr 2021 04:18:55 -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=fm3; bh= 953X5uXJcka/Yb30BgUGAOxlZm+RrfRtJuhNhOIa7Mc=; b=jjcWTucBNSWAv4Rn GS567lz6IFH8USD9whxciK5LkhmQh0BTf5v1bWao57az+SvVqbzQ7puoErl8tx97 SK+6YLoJV1WNYaY+YIRvn/qVXseclsVyzDkfQTEbwKTtjLNZDuzv/31VVbvFunUi FSqVCdCGLQ478Z7ghdjIAx60299Iu03HZP73NmTrKZF7djIyi+urC5l/Mx5NFYiU LJ7GSfmiDtUnhv3oySTtOU2e3TSQfXRzXZYPluBH8c92+xmGBOc/9yj8rI7wU5sa PHEyc+gpGDC6NfhOff51RYuuWVTVkk2bBxqwtvWg2BYYSLMeULSK2sxGau7wHlXg TyOh2Q== 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=953X5uXJcka/Yb30BgUGAOxlZm+RrfRtJuhNhOIa7 Mc=; b=CV6FE+t+C0crwaiO/MyksefTK49Frezg9VhwdJwUpoti6T5DuTO9CUHn6 VUUtsMDwheHoHAgt2kil8csRrSPX+rXktdvfWvGTfJevPiKQN9le0JZuT7rLMj4u BocNVy/E/WsaIjDEKygTOIyULzfTVPk8vAOOnAwT+hJA8XyO1j4ZYIrWef0OJMKv kMyS3lR1HfctQ4nN3CzAAfW5mqOOEpe8yC81f5zKhJiWxzd0GUP4xzDoM4fvyh7l XyxKvIK4On6GVs939uhOE/sKhfWNilsKQN4Ueq3T5ZdCNDrDmctIEkVWUiBcIYdH FiKXtvFA7aMzpDGfaNsgeL/6FURkw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeluddgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght 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 247801080068; Wed, 14 Apr 2021 04:18:53 -0400 (EDT) From: Thomas Monjalon To: Akhil Goyal Cc: Jerin Jacob Kollanukkaran , "dev@dpdk.org" , Ray Kinsella , David Marchand , "abhinandan.gujjar@intel.com" , "hemant.agrawal@nxp.com" , "nipun.gupta@nxp.com" , "sachin.saxena@oss.nxp.com" , Anoob Joseph , "matan@nvidia.com" , "roy.fan.zhang@intel.com" , "g.singh@nxp.com" , "erik.g.carrillo@intel.com" , "jay.jayatheerthan@intel.com" , Pavan Nikhilesh Bhagavatula , "harry.van.haaren@intel.com" , Shijith Thotton Date: Wed, 14 Apr 2021 10:18:52 +0200 Message-ID: <2815780.tZErNpM5md@thomas> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v8 1/3] eventdev: introduce crypto adapter enqueue API 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 Sender: "dev" 14/04/2021 09:58, Akhil Goyal: > Hi, > > > + > > > #define RTE_EVENTDEV_NAME_MAX_LEN (64) > > > /**< @internal Max length of name of event PMD */ > > > > > > @@ -1423,6 +1427,8 @@ struct rte_eventdev { > > > */ > > > event_tx_adapter_enqueue txa_enqueue; > > > /**< Pointer to PMD eth Tx adapter enqueue function. */ > > > + event_crypto_adapter_enqueue ca_enqueue; > > > + /**< Pointer to PMD crypto adapter enqueue function. */ > > > struct rte_eventdev_data *data; > > > /**< Pointer to device data */ > > > struct rte_eventdev_ops *dev_ops; > > > @@ -1435,7 +1441,7 @@ struct rte_eventdev { > > > /**< Flag indicating the device is attached */ > > > > > > uint64_t reserved_64s[4]; /**< Reserved for future fields */ > > > - void *reserved_ptrs[4]; /**< Reserved for future fields */ > > > + void *reserved_ptrs[3]; /**< Reserved for future fields */ > > > } __rte_cache_aligned; > > > > > > This change has following ABI breakage[1]. > > > > Could you move ca_enqueue at end of struct to avoid the ABI breakage. Also, > > please update depreciation notice to move ca_enqueue to above(to align > > with function pointers) in 21.11 release. > > > > [1] > > [C]'function rte_eventdev* rte_event_pmd_allocate(const char*, int)' at > > rte_eventdev.c:1467:1 has some indirect sub-type changes: > > return type changed: > > in pointed to type 'struct rte_eventdev' at rte_eventdev.h:1411:1: > > type size hasn't changed > > 1 data member insertion: > > 'event_crypto_adapter_enqueue rte_eventdev::ca_enqueue', at offset > > 512 (in bits) at rte_eventdev.h:1430:1 > > 5 data member changes: > > 'rte_eventdev_data* rte_eventdev::data' offset changed from 512 to > > 576 (in bits) (by +64 bits) > > 'rte_eventdev_ops* rte_eventdev::dev_ops' offset changed from 576 to > > 640 (in bits) (by +64 bits) > > 'rte_device* rte_eventdev::dev' offset changed from 640 to 704 (in bits) > > (by +64 bits) > > 'uint64_t rte_eventdev::reserved_64s[4]' offset changed from 768 to > > 832 (in bits) (by +64 bits) > > type of 'void* rte_eventdev::reserved_ptrs[4]' changed: > > type name changed from 'void*[4]' to 'void*[3]' > > array type size changed from 256 to 192 > > array type subrange 1 changed length from 4 to 3 > > and offset changed from 1024 to 1088 (in bits) (by +64 bits) > > > > > Yes my bad, it should be added in the end. > But abi script will still shout for 'void*[4]' to 'void*[3]' conversion. > We may need to add something in the devtools/libabigail.abignore > So that, CI is not broken when reserved fields are changed. > Otherwise, it does not make sense to introduce reserve fields. > Can we have something generic for reserved fields? > Any suggestions? The ABI check is not aware about the reserved fields. It needs to be added in libabigail.ignore.