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 AB3BEA04AD; Tue, 8 Feb 2022 10:27:54 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8B987410FD; Tue, 8 Feb 2022 10:27:54 +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 C4B2F410FC for ; Tue, 8 Feb 2022 10:27:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1644312472; 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=1yFWUud9tmfQ8jRWJIfCx/Vl4bd67OTaYkwZNuMN3SY=; b=HBMbDOf9D1HM2Er4kCBlViYqx+ZlPgmJxIWq6qhiPajTGYO6dcgZXkyBOuz/XmTw7fYc2S KrEGOSIUqlcmTuutzU/r0eVOV2wLFunusinOv32KsL98lgCvOnPfFYAIPyYA+dbZJaM1vK jIPyqHekKpkyBO16mIs5TRISBlpGzus= Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-636-KDSSaesJN7KCFWy3qVvVOQ-1; Tue, 08 Feb 2022 04:27:49 -0500 X-MC-Unique: KDSSaesJN7KCFWy3qVvVOQ-1 Received: by mail-lj1-f199.google.com with SMTP id bd23-20020a05651c169700b0023bc6f845beso5826503ljb.17 for ; Tue, 08 Feb 2022 01:27:48 -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=1yFWUud9tmfQ8jRWJIfCx/Vl4bd67OTaYkwZNuMN3SY=; b=sDRk5KgNzRfuK8gLUNNna+rMBeUaAB95SnabRvHwJniy6xcikEC4mrkvgChlO0dGq1 bCP3c5/UiA+N8DsR91iqoNUTRRezk241Fdn70U37j3wKW6NE8UlEDf6nyogQlmgip0fJ nuIX52BGh8SDCSPD1i0xHFRkrOVE4XSd8kxPgWG6G0hmGefi7ecz/+O5/HbrYDAoNhES j/LELgg0e8j0KbGdL/zZ07+fCOwd4TbTAcIQi7sxaP50djTyJGZoD3Iu6iu1ZBLAVPcX Gxj745Zu+fRQUdrHLBOnY4AI/0HynMPLil/UtI/AZGKD+6KPt5xZjwHRS9tR3n731Bib jycQ== X-Gm-Message-State: AOAM530QC65/+2fjDwWgKWqQEuuT2+l3za8gsMjDCcuNQH/F9D9aGQ9y DS1opRgp7IzkgDsnk6tfljSLlgrZKH7b4o9ZI4W0roR2ontoDF0h9n1fiEefGRqaDTSQ2es9QPH r/lrjsM03xge4zo5iyR4= X-Received: by 2002:a2e:b444:: with SMTP id o4mr2334559ljm.477.1644312467495; Tue, 08 Feb 2022 01:27:47 -0800 (PST) X-Google-Smtp-Source: ABdhPJxJvK7cwBwpTmVYI4PbrhZjoZQfQeylz2ubfyxI3QKnobA4m3WkO8gsb1GWnTPwmJgTQWUnvaWrrApzlHQRtjA= X-Received: by 2002:a2e:b444:: with SMTP id o4mr2334549ljm.477.1644312467264; Tue, 08 Feb 2022 01:27:47 -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: From: David Marchand Date: Tue, 8 Feb 2022 10:27:35 +0100 Message-ID: Subject: Re: [EXT] 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 On Tue, Feb 8, 2022 at 10:19 AM Akhil Goyal wrote: > > > 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)? > > > This was discussed here. > http://patches.dpdk.org/project/dpdk/patch/20211008204516.3497060-3-gakhil@marvell.com/ > rte_security_ipsec_sa_options is being used at multiple places as listed below in abiignore. > Checking a particular field in each of the API does not make sense to me. It's strange to me that a user may pass this structure as input in multiple functions. But if it's how the security lib works, ok. > > > > > > > > > > > Signed-off-by: Akhil Goyal > > > Change-Id: I6f66f0b5a659550976a32629130594070cb16cb1 > > ^^^ > > Internal tag, please remove. > > > Yes, missed that will 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} > > > I tried this in the first place but abi check was complaining in other structures which included > rte_security_ipsec_sa_options. So I had to add suppression for those as well. > Can you try at your end? I tried before suggesting, and it works with a single rule on this structure. I'm using libabigail current master, which version are you using so I can try with the same? -- David Marchand