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 1CE5EA0C47; Tue, 12 Oct 2021 10:53:48 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 96BC3410E4; Tue, 12 Oct 2021 10:53:47 +0200 (CEST) Received: from mail-108-mta204.mxroute.com (mail-108-mta204.mxroute.com [136.175.108.204]) by mails.dpdk.org (Postfix) with ESMTP id 21C2340E0F for ; Tue, 12 Oct 2021 10:53:45 +0200 (CEST) Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta204.mxroute.com (ZoneMTA) with ESMTPSA id 17c73b527110000b55.001 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Tue, 12 Oct 2021 08:53:44 +0000 X-Zone-Loop: b624c204d27c974d544db1bf076c6cb40bb9e936555d X-Originating-IP: [149.28.56.236] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ashroe.eu; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=WQqlUHxc0qXNCr8uT8noaV843xLXlcHzyCUuEglQDQ0=; b=pSQ9OnfXu1gBuhWtHPyh6hfBbY F+ShzvrOKMr0ScgMpzCLFnBhbCZXyD0Fo0iN8ek5onptF0mS4UfBeVePxPFkrJV3QgMrGffHrglg8 ljF0F6P3Qb/K/gwHjsvsYm86r4EztajQ/74aQmJ5/FDT5PyfhqjbPTI2SZp3qGJFnIU1YzEblh+gr IuzVUh/X0jOh1vW9GDrwP9N5ib/E/1HTJayixRBCRTV2iM+IBbWADVO5HeBDfAA6Gx3nlxwLA4XoX kTDuUNPOUk+Q1a4q78lXrgxubKnrmqPpOzJfICH6JymHibCcwKzUQcbOM827SEANNFeYjpPS3cQZs O16JUPnA==; To: dev@dpdk.org References: <20210731181327.660296-1-gakhil@marvell.com> <2663373.9MILaYa0Np@thomas> <6054165.9aso14lfZU@thomas> From: "Kinsella, Ray" Message-ID: <1e738c47-27d5-e852-9f76-d512faf65d42@ashroe.eu> Date: Tue, 12 Oct 2021 09:53:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <6054165.9aso14lfZU@thomas> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-AuthUser: mdr@ashroe.eu X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-0.1, required=15, tests=[ARC_NA=0, NEURAL_SPAM=0, FROM_HAS_DN=0, MIME_GOOD=-0.1, FROM_EQ_ENVFROM=0, MIME_TRACE=0, RCVD_COUNT_ZERO=0, RCPT_COUNT_ONE=0, MID_RHS_MATCH_FROM=0, TO_DN_NONE=0] Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v2 3/3] security: add reserved bitfields 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 Sender: "dev" On 12/10/2021 07:59, Thomas Monjalon wrote: > 11/10/2021 18:58, Akhil Goyal: >>> 08/10/2021 22:45, Akhil Goyal: >>>> In struct rte_security_ipsec_sa_options, for every new option >>>> added, there is an ABI breakage, to avoid, a reserved_opts >>>> bitfield is added to for the remaining bits available in the >>>> structure. >>>> Now for every new sa option, these reserved_opts can be reduced >>>> and new option can be added. >>> >>> How do you make sure this field is initialized to 0? >>> >> Struct rte_security_ipsec_xform Is part of rte_security_capability as well >> As a configuration structure in session create. >> User, should ensure that if a device support that option(in capability), then >> only these options will take into effect or else it will be don't care for the PMD. >> The initial values of capabilities are set by PMD statically based on the features >> that it support. >> So if someone sets a bit in reserved_opts, it will work only if PMD support it >> And sets the corresponding field in capabilities. >> But yes, if a new field is added in future, and user sets the reserved_opts by mistake >> And the PMD supports that feature as well, then that feature will be enabled. >> This may or may not create issue depending on the feature which is enabled. >> >> Should I add a note in the comments to clarify that reserved_opts should be set as 0 >> And future releases may change this without notice(But reserved in itself suggest that)? >> Adding an explicit check in session_create does not make sense to me. >> What do you suggest? > > Yes at the minimum you should add a comment. > You could also initialize it in the lib, but it is not always possible. > Provide a macro for initialization perhaps ... but there would be no way to enforce using it. Ray K