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 43FA542C53; Wed, 7 Jun 2023 21:49:37 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C9B77427E9; Wed, 7 Jun 2023 21:49:36 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 539AF41611 for ; Wed, 7 Jun 2023 21:49:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1686167374; 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=52cSM9yQmuDwmPeoM/gnUL++mXmgrI+1SOgzg1qMlbM=; b=e8793NeE5kU8kyvK6MQblz4WeD62YXQQx4G246JdJMfbCQ3ZzR6B7fXtrcCJ+w2ICzOTeS +kSGnq1mYq9pb19h5QbIVqYzfjDsa8y/RB6FyiTlcTYUCeXOLilA3a/N1qCprQDcgKYyfN pcDd47hW3Be6Sdtms/Tn5SnEeWobif0= Received: from mail-pj1-f69.google.com (mail-pj1-f69.google.com [209.85.216.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-600-zxy3-d4eMuO441FlS46uiw-1; Wed, 07 Jun 2023 15:49:23 -0400 X-MC-Unique: zxy3-d4eMuO441FlS46uiw-1 Received: by mail-pj1-f69.google.com with SMTP id 98e67ed59e1d1-256563a2097so2602605a91.0 for ; Wed, 07 Jun 2023 12:49:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686167363; x=1688759363; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=52cSM9yQmuDwmPeoM/gnUL++mXmgrI+1SOgzg1qMlbM=; b=aleWf+dCPJRjtWjIfAqvHGQgPM/FO+JSzHhjw0stfWJyGrq/qVcVeyqljR+Tzj42aY vQF5ms3FGPpAvnMD2LjmVNVPlSYQak6UF23+azkkKg9e2os47NnNVjdEt+GiEx0jg/kG M6V8vXcEsWHL1pNgRuaWc07pyyzmVm5GqO+hC3T5Ub7+D5oFxdxQDDi/aSAYV4uwz3uk rexYMCFCAXKAJwH62QzjrzxA49rpqRVwJA4E43eYAhUSYaqm17FjWRTrZgqnGgipUrHF G+LgWBXH6elCG9s7/k4YrqjVfGDlbGY8QedCqBMzc5w829gJ7GcIXzeer5vNd+CeJ3un LwOw== X-Gm-Message-State: AC+VfDzbGpFnMYTTDjISfhW2tDzAB37qejXHaZQlyeqxYeiOr6VJmlIQ gaDYcpbI0njG0e+JMa9fV72WuQ18PlTsV5RXo8S5v1LX1LtdCqH38a2PcCe4UrMIzHn/8XCAQGd XzHvnupWsSAgHuaL4NvM= X-Received: by 2002:a17:90a:d3d4:b0:256:33ba:8f5f with SMTP id d20-20020a17090ad3d400b0025633ba8f5fmr2468240pjw.36.1686167362821; Wed, 07 Jun 2023 12:49:22 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7QHv+sXgDPr/EPrWT2JEgF4uI906xLroPujpHkGX7oaNr8FCHAg8M0xL7x3OlH8ddtKuSTY0CQN6GKOctyzAU= X-Received: by 2002:a17:90a:d3d4:b0:256:33ba:8f5f with SMTP id d20-20020a17090ad3d400b0025633ba8f5fmr2468223pjw.36.1686167362544; Wed, 07 Jun 2023 12:49:22 -0700 (PDT) MIME-Version: 1.0 References: <20230523194918.1940212-1-gakhil@marvell.com> <20230607151940.223417-1-gakhil@marvell.com> <20230607151940.223417-2-gakhil@marvell.com> In-Reply-To: <20230607151940.223417-2-gakhil@marvell.com> From: David Marchand Date: Wed, 7 Jun 2023 21:49:11 +0200 Message-ID: Subject: Re: [PATCH v2 01/13] security: add direction in SA/SC configuration To: Akhil Goyal Cc: dev@dpdk.org, thomas@monjalon.net, olivier.matz@6wind.com, orika@nvidia.com, hemant.agrawal@nxp.com, vattunuru@marvell.com, ferruh.yigit@amd.com, andrew.rybchenko@oktetlabs.ru, jerinj@marvell.com, adwivedi@marvell.com, Dodji Seketeli X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Wed, Jun 7, 2023 at 5:20=E2=80=AFPM Akhil Goyal wro= te: > > MACsec SC/SA ids are created based on direction of the flow. > Hence, added the missing field for configuration and cleanup > of the SCs and SAs. > > Signed-off-by: Akhil Goyal > --- > devtools/libabigail.abignore | 7 +++++++ > lib/security/rte_security.c | 16 ++++++++++------ > lib/security/rte_security.h | 14 ++++++++++---- > lib/security/rte_security_driver.h | 12 ++++++++++-- > 4 files changed, 37 insertions(+), 12 deletions(-) > Looking at the report with no supression rule: $ abidiff --suppr .../next-cryptodev/devtools/libabigail.abignore --no-added-syms --headers-dir1 .../abi/v23.03/build-gcc-shared/usr/local/include --headers-dir2 .../next-cryptodev/build-gcc-shared/install/usr/local/include .../abi/v23.03/build-gcc-shared/usr/local/lib64/librte_security.so.23.1 .../next-cryptodev/build-gcc-shared/install/usr/local/lib64/librte_security= .so.23.2 Functions changes summary: 0 Removed, 1 Changed (13 filtered out), 0 Added functions Variables changes summary: 0 Removed, 0 Changed, 0 Added variable 1 function with some indirect sub-type change: [C] 'function const rte_security_capability* rte_security_capabilities_get(rte_security_ctx*)' at rte_security.c:241:1 has some indirect sub-type changes: parameter 1 of type 'rte_security_ctx*' has sub-type changes: in pointed to type 'struct rte_security_ctx' at rte_security.h:69:1: type size hasn't changed 1 data member change: type of 'const rte_security_ops* ops' changed: in pointed to type 'const rte_security_ops': in unqualified underlying type 'struct rte_security_ops' at rte_security_driver.h:230:1: type size hasn't changed 4 data member changes (4 filtered): type of 'security_macsec_sc_create_t macsec_sc_create' changed: underlying type 'int (void*, rte_security_macsec_sc*)*' changed: in pointed to type 'function type int (void*, rte_security_macsec_sc*)': parameter 2 of type 'rte_security_macsec_sc*' has sub-type changes: in pointed to type 'struct rte_security_macsec_sc' at rte_security.h:399:1: type size changed from 256 to 320 (in bits) 1 data member insertion: 'union {struct {uint16_t sa_id[4]; uint8_t sa_in_use[4]; uint8_t active; uint8_t is_xpn; uint8_t reserved;} sc_rx; struct {uint16_t sa_id; uint16_t sa_id_rekey; uint64_t sci; uint8_t active; uint8_t re_key_en; uint8_t is_xpn; uint8_t reserved;} sc_tx;}', at offset 128 (in bits) 1 data member change: anonymous data member union {struct {uint16_t sa_id[4]; uint8_t sa_in_use[4]; uint8_t active; uint8_t reserved;} sc_rx; struct {uint16_t sa_id; uint16_t sa_id_rekey; uint64_t sci; uint8_t active; uint8_t re_key_en; uint8_t reserved;} sc_tx;} at offset 64 (in bits) became data member 'uint64_t pn_threshold' and size changed from 192 to 64 (in bits) (by -128 bits) type of 'security_macsec_sc_destroy_t macsec_sc_destroy' changed: underlying type 'int (void*, typedef uint16_t)*' change= d: in pointed to type 'function type int (void*, typedef uint16_t)': parameter 3 of type 'enum rte_security_macsec_direction' was added type of 'security_macsec_sc_stats_get_t macsec_sc_stats_get' changed: underlying type 'int (void*, typedef uint16_t, rte_security_macsec_sc_stats*)*' changed: in pointed to type 'function type int (void*, typedef uint16_t, rte_security_macsec_sc_stats*)': parameter 3 of type 'rte_security_macsec_sc_stats*' changed: entity changed from 'rte_security_macsec_sc_stats*' to 'enum rte_security_macsec_direction' at rte_security.h:361:1 type size changed from 64 to 32 (in bits) type alignment changed from 0 to 32 parameter 4 of type 'rte_security_macsec_sc_stats*' was added type of 'security_macsec_sa_stats_get_t macsec_sa_stats_get' changed: underlying type 'int (void*, typedef uint16_t, rte_security_macsec_sa_stats*)*' changed: in pointed to type 'function type int (void*, typedef uint16_t, rte_security_macsec_sa_stats*)': parameter 3 of type 'rte_security_macsec_sa_stats*' changed: entity changed from 'rte_security_macsec_sa_stats*' to 'enum rte_security_macsec_direction' at rte_security.h:361:1 type size changed from 64 to 32 (in bits) type alignment changed from 0 to 32 parameter 4 of type 'rte_security_macsec_sa_stats*' was added The report complains about the macsec ops type changes. > diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore > index c0361bfc7b..14d8fa4293 100644 > --- a/devtools/libabigail.abignore > +++ b/devtools/libabigail.abignore > @@ -37,6 +37,13 @@ > [suppress_type] > type_kind =3D enum > changed_enumerators =3D RTE_CRYPTO_ASYM_XFORM_ECPM, RTE_CRYPTO_A= SYM_XFORM_TYPE_LIST_END > +; Ignore changes to rte_security_ops MACsec APIs which are experimental > +[suppress_type] > + name =3D rte_security_ops > + has_data_member_inserted_between =3D > + { > + offset_of(security_macsec_sc_create_t), offset_of(securi= ty_macsec_sa_stats_get_t) > + } So I don't get the intent with this rule. There is no field named neither security_macsec_sc_create_t nor security_macsec_sa_stats_get_t in the rte_security_ops struct. Now.. why is this rule making the check pass... it is a mystery to me. I already hit a case when libabigail ignored statements that are invalid or make no sense, so my guess is that this rule is actually applied as a simple: [suppress_type] name =3D rte_security_ops And well, this rule is ok from my pov: this rte_security_ops struct does not change in size. An application is not supposed to know about its content (that is defined in a driver header) and all accesses to those ops are supposed to be through symbols from the security library. So I would go with this "larger" and simpler rule. Just a small addition to this, as discussed offlist, this is going to be reworked in v23.11 and this rule on rte_security_ops will be unneccesary, so please move it in the relevant block (at the end) of the libabigail.abignore file. --=20 David Marchand