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 C9BDB42C35; Mon, 5 Jun 2023 21:08:45 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B8C114021F; Mon, 5 Jun 2023 21:08:45 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id A1F6D4003C for ; Mon, 5 Jun 2023 21:08:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1685992124; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jAiJehTYYL7QqscGy3bHTvzJkgl6w99cGMqVEiid0ME=; b=V2P6U6A0vRfV0iRfC4MNNH0petUwtnx34gWFMSiE5KqwETDGmsXHoDqMVqIFpTJ1cvF3Oh qLHfOHHRhHy4eW1CtVtjMMb3F95cRIaTPrkEd0NOEIdvD6AakuNeWtoCDsSWYhOiTWNPv+ OBET72XbRZwf+MCgZa8ealdXdoBMcPs= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-425-icUTIzY-OkKfD8euErDYyg-1; Mon, 05 Jun 2023 15:08:38 -0400 X-MC-Unique: icUTIzY-OkKfD8euErDYyg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C32DF8028B1; Mon, 5 Jun 2023 19:08:37 +0000 (UTC) Received: from [10.39.208.25] (unknown [10.39.208.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D4F657AE4; Mon, 5 Jun 2023 19:08:36 +0000 (UTC) Message-ID: <62ae4556-7a8b-3283-2df8-927415114745@redhat.com> Date: Mon, 5 Jun 2023 21:08:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH v1 1/1] bbdev: extend range of allocation function To: "Chautru, Nicolas" , "dev@dpdk.org" Cc: "hemant.agrawal@nxp.com" , "Vargas, Hernan" References: <20230602020423.426465-1-nicolas.chautru@intel.com> <20230602020423.426465-2-nicolas.chautru@intel.com> From: Maxime Coquelin In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 On 6/2/23 16:17, Chautru, Nicolas wrote: > Hi Maxime, > I don't think it does since no offset position change for the symbol. Also this only extends the type, so still fine if using uin16_t from application. > I did not receive an email from CICD related to ABI change when pushing this (unlike the other serie for the MLD/FFT changes pushed earlier this week). > Still let me know if you would like this added as well into deprecation notice, but it doesn't look required. If ABI checks are OK, then this is good to me. Thanks, Maxime > Thanks > Nic > >> -----Original Message----- >> From: Maxime Coquelin >> Sent: Friday, June 2, 2023 12:56 AM >> To: Chautru, Nicolas ; dev@dpdk.org >> Cc: hemant.agrawal@nxp.com; Vargas, Hernan >> Subject: Re: [PATCH v1 1/1] bbdev: extend range of allocation function >> >> >> >> On 6/2/23 04:04, Nicolas Chautru wrote: >>> Realigning the argument to unsigned int to align with number support >>> by underlying rte_mempool_get_bulk function. >>> >>> Signed-off-by: Nicolas Chautru >>> --- >>> lib/bbdev/rte_bbdev_op.h | 6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h index >>> 96a390cd9b..9353fd588b 100644 >>> --- a/lib/bbdev/rte_bbdev_op.h >>> +++ b/lib/bbdev/rte_bbdev_op.h >>> @@ -982,7 +982,7 @@ rte_bbdev_op_pool_create(const char *name, >> enum rte_bbdev_op_type type, >>> */ >>> static inline int >>> rte_bbdev_enc_op_alloc_bulk(struct rte_mempool *mempool, >>> - struct rte_bbdev_enc_op **ops, uint16_t num_ops) >>> + struct rte_bbdev_enc_op **ops, unsigned int num_ops) >>> { >>> struct rte_bbdev_op_pool_private *priv; >>> >>> @@ -1013,7 +1013,7 @@ rte_bbdev_enc_op_alloc_bulk(struct >> rte_mempool *mempool, >>> */ >>> static inline int >>> rte_bbdev_dec_op_alloc_bulk(struct rte_mempool *mempool, >>> - struct rte_bbdev_dec_op **ops, uint16_t num_ops) >>> + struct rte_bbdev_dec_op **ops, unsigned int num_ops) >>> { >>> struct rte_bbdev_op_pool_private *priv; >> >> Isn't it breaking the ABI? >> >>> @@ -1045,7 +1045,7 @@ rte_bbdev_dec_op_alloc_bulk(struct >> rte_mempool *mempool, >>> __rte_experimental >>> static inline int >>> rte_bbdev_fft_op_alloc_bulk(struct rte_mempool *mempool, >>> - struct rte_bbdev_fft_op **ops, uint16_t num_ops) >>> + struct rte_bbdev_fft_op **ops, unsigned int num_ops) >>> { >>> struct rte_bbdev_op_pool_private *priv; >>> >