From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 6C57345BFE;
Mon, 28 Oct 2024 12:15:54 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 3E6CA402A3;
Mon, 28 Oct 2024 12:15:54 +0100 (CET)
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 1962C400D7
for <dev@dpdk.org>; Mon, 28 Oct 2024 12:15:52 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1730114152;
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:
in-reply-to:in-reply-to:references:references;
bh=0ineCCVwy8Hz0wJe03VH3uZFeLhFa958hOCojM+nPak=;
b=f7ZbTWeDPmiYH4Pgnm36vLY8K9Wdhc/7qw89hLhgwCcce4bh5vnS2gGLbnG2zWdbwBlfaE
0+NPfjp5NHq8m8amoEXfxe71IaGMxiOuNeJerIFP2yaocTtzbJZdSE0n6Qkm5/LmVTF0iI
neQ1yigOkFOhflIYN7FGXU1GstgSohE=
Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com
[209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS
(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
us-mta-661-xFpXMevgM4uI4cTP4eCF-Q-1; Mon, 28 Oct 2024 07:15:50 -0400
X-MC-Unique: xFpXMevgM4uI4cTP4eCF-Q-1
Received: by mail-qk1-f198.google.com with SMTP id
af79cd13be357-7b14cb9f6f5so794233685a.0
for <dev@dpdk.org>; Mon, 28 Oct 2024 04:15:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1730114150; x=1730718950;
h=mime-version:user-agent:message-id:in-reply-to:date:references
:organization:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=0ineCCVwy8Hz0wJe03VH3uZFeLhFa958hOCojM+nPak=;
b=YUcXQAqxUbqNUMXFnQeGMmb9OunfF85bncU0phMxX1xS/9COLP+4IBuHYpfB1ZVQ+m
IKJqQrA8LJJuKpButyYwh1sraIJgnlzCqnOIFygswVUfgjtFF55owth17iFwbE7JrzHh
Oi2Mq8/2fWwHrslkigLmPQ5tPHeIFCvQDcu+Jjh7BIZbq4s7759M7hb47HAYEI/crwKN
/KU/NkLsQOqUkv/wxMRuP8bwhkZYZYm7lLIf6eDP8Tt829tdLISQtM/5ZgC3mQ05Dsra
ZlRz3lhLEgzvltYYaATr1vxZsV0zJCVf/duNJif/fsAv8cDHC/QD7tj9P0+2YbCgWkEY
odsg==
X-Forwarded-Encrypted: i=1;
AJvYcCXkb8P6Wx3bpIYQKI1ShpzU9KpjkUclDePT7RwQbMhqpyRCAg1hGXsLhbzoB3zkAhPDSmA=@dpdk.org
X-Gm-Message-State: AOJu0Yy/6dNlKBlcUp+Pq7Za+6vyO5GkJwmw59ngRklPQZ3qoyQ4Vo+h
ItoHVDuz5sXEzeR1YGEqymBkJOVDFubjKQna7d0l4qmdW75l50KGHorWegplPI5Novl1kXTopBb
vrftK+7puFAbwBgKXnjpvCez3UqTY3DcdTjnyTKUy
X-Received: by 2002:a05:620a:290f:b0:7b1:1236:f3d6 with SMTP id
af79cd13be357-7b193ef9fd6mr1545797685a.15.1730114148433;
Mon, 28 Oct 2024 04:15:48 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IHmKRU5kwmqrq4TxNh9OshAkV3RWy+gnRWmomohBysTl8vaGPXf9Zp2ya6fi+8JrdRtP3pSbQ==
X-Received: by 2002:a05:620a:290f:b0:7b1:1236:f3d6 with SMTP id
af79cd13be357-7b193ef9fd6mr1545785285a.15.1730114146682;
Mon, 28 Oct 2024 04:15:46 -0700 (PDT)
Received: from localhost (88-120-130-27.subs.proxad.net. [88.120.130.27])
by smtp.gmail.com with ESMTPSA id
af79cd13be357-7b18d3456f3sm307584085a.122.2024.10.28.04.15.45
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 28 Oct 2024 04:15:46 -0700 (PDT)
Received: by localhost (Postfix, from userid 1000)
id D5C7A5073C45; Mon, 28 Oct 2024 12:15:43 +0100 (CET)
From: Dodji Seketeli <dodji@redhat.com>
To: Akhil Goyal <gakhil@marvell.com>
Cc: Ferruh Yigit <ferruh.yigit@amd.com>, David Marchand
<david.marchand@redhat.com>, "dev@dpdk.org" <dev@dpdk.org>, Dodji
Seketeli <dodji@redhat.com>, "thomas@monjalon.net" <thomas@monjalon.net>,
"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>, Anoob Joseph
<anoobj@marvell.com>, "pablo.de.lara.guarch@intel.com"
<pablo.de.lara.guarch@intel.com>, "fiona.trahe@intel.com"
<fiona.trahe@intel.com>, "declan.doherty@intel.com"
<declan.doherty@intel.com>, "matan@nvidia.com" <matan@nvidia.com>,
"g.singh@nxp.com" <g.singh@nxp.com>, "fanzhang.oss@gmail.com"
<fanzhang.oss@gmail.com>, "jianjay.zhou@huawei.com"
<jianjay.zhou@huawei.com>, "asomalap@amd.com" <asomalap@amd.com>,
"ruifeng.wang@arm.com" <ruifeng.wang@arm.com>,
"konstantin.v.ananyev@yandex.ru" <konstantin.v.ananyev@yandex.ru>,
"radu.nicolau@intel.com" <radu.nicolau@intel.com>,
"ajit.khaparde@broadcom.com" <ajit.khaparde@broadcom.com>, Nagadheeraj
Rottela <rnagadheeraj@marvell.com>, "mdr@ashroe.eu" <mdr@ashroe.eu>
Subject: Re: [EXTERNAL] Re: [PATCH] [RFC] cryptodev: replace LIST_END
enumerators with APIs
Organization: Red Hat / France
References: <20240905101438.3888274-1-gakhil@marvell.com>
<10591cfb-d78e-4d50-9bb5-f6d1246662b3@amd.com>
<CAJFAV8xETZEGOA9xpazhjzAuKTRvWsqJ=RfqdsbUsvbJpsQi7w@mail.gmail.com>
<02390115-de83-48be-b410-b1b94e5a9dea@amd.com>
<CO6PR18MB4484C8F17CA2021E7AD5FCE8D8782@CO6PR18MB4484.namprd18.prod.outlook.com>
X-Operating-System: AlmaLinux 9.4
X-URL: http://www.redhat.com
Date: Mon, 28 Oct 2024 12:15:43 +0100
In-Reply-To: <CO6PR18MB4484C8F17CA2021E7AD5FCE8D8782@CO6PR18MB4484.namprd18.prod.outlook.com>
(Akhil Goyal's message of "Thu, 10 Oct 2024 06:18:52 +0000")
Message-ID: <87h68w32cg.fsf@redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Akhil Goyal <gakhil@marvell.com> writes:
>> >>> Now added inline APIs for getting the list end which need to be updated
>> >>> for each new entry to the enum. This shall help in avoiding ABI break
>> >>> for adding new algo.
>> >>>
>> >>
>> >> Hi Akhil,
>> >>
>> >> *I think* this hides the problem instead of fixing it, and this may be
>> >> partially because of the tooling (libabigail) limitation.
>> >>
>> >> This patch prevents the libabigail warning, true, but it doesn't improve
>> >> anything from the application's perspective.
>> >> Before or after this patch, application knows a fixed value as END value.
>> >>
>> >> Not all changes in the END (MAX) enum values cause ABI break, but tool
>> >> warns on all, that is why I think this may be tooling limitation [1].
>> >> (Just to stress, I am NOT talking about regular enum values change, I am
>> >> talking about only END (MAX) value changes caused by appending new enum
>> >> items.)
>> >>
>> >> As far as I can see (please Dodji, David correct me if I am wrong) ABI
>> >> break only happens if application and library exchange enum values in
>> >> the API (directly or within a struct).
>> >
>> > - There is also the following issue:
>> > A library publicly exports an array sized against a END (MAX) enum in the API.
>> > https://developers.redhat.com/blog/2019/05/06/how-c-array-sizes-become-part-of-the-binary-interface-of-a-library
>> >
>>
>> I see. And Dodji explained this requires source code to detect.
>>
>> I don't remember seeing a public array whose size is defined by an enum,
>> are you aware of any instance of this usage?
>
> https://patches.dpdk.org/project/dpdk/patch/20241009071151.1106-1-gmuthukrishn@marvell.com/
> This was merged yesterday.
I guess the problematic piece of the code is this:
diff --git a/lib/cryptodev/rte_cryptodev.h
b/lib/cryptodev/rte_cryptodev.h
index bec947f6d5..aa6ef3a94d 100644
--- a/lib/cryptodev/rte_cryptodev.h
+++ b/lib/cryptodev/rte_cryptodev.h
@@ -185,6 +185,9 @@ struct rte_cryptodev_asymmetric_xform_capability {
* Value 0 means unavailable, and application should pass the
required
* random value. Otherwise, PMD would internally compute
the random number.
*/
+
+ uint32_t op_capa[RTE_CRYPTO_ASYM_OP_LIST_END];
+ /**< Operation specific capabilities. */
};
Is it possible for the struct rte_cryptodev_asymmetric_xform_capability
to be made an opaque struct which definition would be present only in a
.c file of the library?
Its data members would then be retrieved by getter functions that take a
pointer to that struct in parameter.
That way, the uint32_t op_capa[RTE_CRYPTO_ASYM_OP_LIST_END] data member
would be "private" to the .c file and thus would not be part of the
ABI. Any change to the RTE_CRYPTO_ASYM_OP enum would then become
harmless to that struct.
I hope this helps.
--
Dodji