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 9B876A04AD; Tue, 8 Feb 2022 10:02:05 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6B08A410FC; Tue, 8 Feb 2022 10:02:05 +0100 (CET) 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 3BD47410F6 for ; Tue, 8 Feb 2022 10:02:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1644310923; 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=zEeBMMI/3TvawmayuPqFdcGVbqwuZqjNc2cMivwPack=; b=Q6De4IlEHwiReZC4uoLvSa2XBXoiTrew9tU95nMiT3W3NDW+7Yfv6C4/DWpc/M4lFzv0r3 Md7mxScSd1QlehVSyHIuSK8vAmffsYvE1zHJ2aavserNT4aevskeDt7Z+G1tOiCm8/AORC 6avw2xilZmH1v6sVk64zRYGyMGliaj4= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-248-OOuySmBgPCiG95LcKWtRHA-1; Tue, 08 Feb 2022 04:02:02 -0500 X-MC-Unique: OOuySmBgPCiG95LcKWtRHA-1 Received: by mail-lf1-f70.google.com with SMTP id s25-20020a056512215900b004406a28c08bso453785lfr.10 for ; Tue, 08 Feb 2022 01:02:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zEeBMMI/3TvawmayuPqFdcGVbqwuZqjNc2cMivwPack=; b=x2zp9fUL9W+A1mua5fj+vw5i17IES94CgJtoAH4tJvjCHB++RbW44GDhQDbFSt6jBz 1DXaqIEuwfweFfUxNy0clqooPADQ6QIkDsVCQFg7ruJf16lqPStC/OCjxj6dFyq0LLwe OnljD5S3iuu9oiPLqNTkq0TAHY8mCQnFTg0jHoJerbYFNiKFER2ZEyHiUKBcyHBGphva dSMvdLYpHP4fqNd3TP8ao3Gal92ZusfgRknFyQl2k2X/h2UZYp6jccvo89CE34JDockm XOKfK42dN68PXwG3J7XwsrQS4ev071WazB3aTIH5V55KRqFQmMmOCKoD0HP+YolCdIh8 Zwuw== X-Gm-Message-State: AOAM530O/wr8mBLXuKHmm+B/vvrwh+JTiKHR7NfING6BtW3ThAi1Sq47 akroSZWwMRH7H1F91mSa93ScyC/69zKZjuXfmUea5eDwsr55zbxB9KXDCngF60iC+KTbX1MwZLD Hag5w8wSNQV2d2wtFXf8= X-Received: by 2002:a05:6512:118e:: with SMTP id g14mr2334092lfr.265.1644310920946; Tue, 08 Feb 2022 01:02:00 -0800 (PST) X-Google-Smtp-Source: ABdhPJyOvc3Bh6vyC3jrXBVqMxHgndAA//1tBrp434FFZqG2DnUvz1nmk9mFPI/qc5vCYfBHuNY/eKKoKXAmKq+YAyA= X-Received: by 2002:a05:6512:118e:: with SMTP id g14mr2334070lfr.265.1644310920668; Tue, 08 Feb 2022 01:02:00 -0800 (PST) MIME-Version: 1.0 References: <20220130175935.1947730-1-gakhil@marvell.com> <20220204221334.3551574-1-gakhil@marvell.com> <20220204221334.3551574-4-gakhil@marvell.com> In-Reply-To: <20220204221334.3551574-4-gakhil@marvell.com> From: David Marchand Date: Tue, 8 Feb 2022 10:01:49 +0100 Message-ID: Subject: Re: [PATCH v4 3/3] security: add IPsec option for IP reassembly To: Akhil Goyal Cc: dev , Anoob Joseph , Matan Azrad , "Ananyev, Konstantin" , Thomas Monjalon , "Yigit, Ferruh" , Andrew Rybchenko , Rosen Xu , Olivier Matz , Radu Nicolau , Jerin Jacob Kollanukkaran , Stephen Hemminger , Ray Kinsella , Dodji Seketeli Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" 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 Hello Akhil, On Fri, Feb 4, 2022 at 11:14 PM Akhil Goyal wrote: > > A new option is added in IPsec to enable and attempt reassembly > of inbound packets. First, about extending this structure. Copying the header: /** Reserved bit fields for future extension * * User should ensure reserved_opts is cleared as it may change in * subsequent releases to support new options. * * Note: Reduce number of bits in reserved_opts for every new option. */ uint32_t reserved_opts : 18; I did not follow the introduction of the reserved_opts field, but writing this comment in the API only is weak. Why can't the rte_security API enforce reserved_opts == 0 (like in rte_security_session_create)? > > Signed-off-by: Akhil Goyal > Change-Id: I6f66f0b5a659550976a32629130594070cb16cb1 ^^^ Internal tag, please remove. > --- > devtools/libabigail.abignore | 14 ++++++++++++++ > lib/security/rte_security.h | 12 +++++++++++- > 2 files changed, 25 insertions(+), 1 deletion(-) > > diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore > index 4b676f317d..3bd39042e8 100644 > --- a/devtools/libabigail.abignore > +++ b/devtools/libabigail.abignore > @@ -11,3 +11,17 @@ > ; Ignore generated PMD information strings > [suppress_variable] > name_regexp = _pmd_info$ > + > +; Ignore fields inserted in place of reserved_opts of rte_security_ipsec_sa_options > +[suppress_type] > + name = rte_ipsec_sa_prm > + name = rte_security_ipsec_sa_options > + has_data_member_inserted_between = {offset_of(reserved_opts), end} > + > +[suppress_type] > + name = rte_security_capability > + has_data_member_inserted_between = {offset_of(reserved_opts), (offset_of(reserved_opts) + 18)} > + > +[suppress_type] > + name = rte_security_session_conf > + has_data_member_inserted_between = {offset_of(reserved_opts), (offset_of(reserved_opts) + 18)} Now, about the suppression rule, I don't understand the intention of those 3 rules. I would simply suppress modifications (after reserved_opts) to the rte_security_ipsec_sa_options struct. Like: ; Ignore fields inserted in place of reserved_opts of rte_security_ipsec_sa_options [suppress_type] name = rte_security_ipsec_sa_options has_data_member_inserted_between = {offset_of(reserved_opts), end} -- David Marchand