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 EAB2CA00C3; Tue, 19 Apr 2022 17:41:27 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 861684068E; Tue, 19 Apr 2022 17:41:27 +0200 (CEST) Received: from mail-108-mta80.mxroute.com (mail-108-mta80.mxroute.com [136.175.108.80]) by mails.dpdk.org (Postfix) with ESMTP id DD51C40687 for ; Tue, 19 Apr 2022 17:41:25 +0200 (CEST) Received: from filter006.mxroute.com ([140.82.40.27] 140.82.40.27.vultrusercontent.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta80.mxroute.com (ZoneMTA) with ESMTPSA id 180427c3b1c000fe85.001 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Tue, 19 Apr 2022 15:41:19 +0000 X-Zone-Loop: fe6cac315b9ea4b0ebe5dcc65ed22dcaa09848397257 X-Originating-IP: [140.82.40.27] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ashroe.eu; s=x; h=Content-Type:MIME-Version:Message-ID:Date:In-reply-to:Subject:Cc:To: From:References:Sender:Reply-To:Content-Transfer-Encoding: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=9aQWt6teDPkHhFQJkhv/yLC3FD5lhxF/84SOednmyog=; b=erNIMY+AAZqnsz2b3OJmiiannJ GKwh2dRRqm9nnVAY2vZmtrH1fdii1JC9jZYQjBYsf4Qx+o31XMlsNJBWKEHCQnffO0ediwQvQHxyE B4MX0pdJGDA2iqtcm1GFIbSXTedxCV1ExZDo7ub2iJdNDP6uSx+6h9wCecUuhNycXFhjsr7ywVzCx LYZeNgViLCmpLUV30OfQnxfU4ppnrj0nzP7PXqVQ9HcHNix19fN5/mihGNrsxQMp14jXjO+yGu8Lu rkOtWUC6zMVMspFBeZWiJp53UchVtDRkkCYPNkENIIcboTi8yNQKrB753DRVi4FA65zpCHuYWRbtv JMhkrnHw==; References: <20220217172341.607360-1-gakhil@marvell.com> <11961195.O9o76ZdvQC@thomas> <4703969.GXAFRqVoOG@thomas> User-agent: mu4e 1.4.15; emacs 27.1 From: Ray Kinsella To: Akhil Goyal Cc: Thomas Monjalon , "dev@dpdk.org" , "david.marchand@redhat.com" , "hemant.agrawal@nxp.com" , Anoob Joseph , "konstantin.ananyev@intel.com" , "ciara.power@intel.com" , "ferruh.yigit@intel.com" , "andrew.rybchenko@oktetlabs.ru" , Nithin Kumar Dabilpuram , Vamsi Krishna Attunuru Subject: Re: [EXT] Re: [PATCH v4 07/10] ethdev: add IPsec SA expiry event subtypes In-reply-to: Date: Tue, 19 Apr 2022 11:41:15 -0400 Message-ID: <87zgkhnkro.fsf@mdr78.vserver.site> MIME-Version: 1.0 Content-Type: text/plain X-AuthUser: mdr@ashroe.eu 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 Akhil Goyal writes: >> > Time expiry means after x seconds SA will expire. >> > Packet expiry means after x packets processing SA will expire. >> > Byte expiry means after x bytes of packet processing SA will expire. >> >> I think you should use the syntax @ref packets_soft_limit >> so it is clear where the event come from. > > OK will update the comments. > >> >> >> > > > + RTE_ETH_EVENT_IPSEC_SA_PKT_EXPIRY, >> > > > + /** Hard byte expiry of SA */ >> > > > + RTE_ETH_EVENT_IPSEC_SA_BYTE_HARD_EXPIRY, >> > > > + /** Hard packet expiry of SA */ >> > > > + RTE_ETH_EVENT_IPSEC_SA_PKT_HARD_EXPIRY, >> > > >> > > Same comment for the 3 events. >> > > >> > > > /** Max value of this enum */ >> > > > RTE_ETH_EVENT_IPSEC_MAX >> > > > }; >> > > >> > > What is the impact of this "MAX" value on ABI compatibility? >> > >> > I see no issues reported while running ABI check. >> > There is no array being used inside library based on MAX. >> >> No need of array inside the library, the events are exposed to the app. >> I'm surprised libabigail is OK with changing an enum value. >> > @Ray Can you please check if it is an issue to add more values in this enum? Well look there is two seperate things going on here. Why isn't libabigail complaining about the _MAX value changing. I'll need to look at libabigail to see what the issue is, so lets put this one aside for a moment. This second issue is it safe for the _MAX value to change? We have a lot of back and forth argument on these, and previously concluded that we should probably look to remove _MAX values in the 22.11 release. The core issue is that we need look at how a user is likely to use rte_eth_event_ipsec_subtype. Take a look at the example below:- /root/src/dpdk/examples/ipsec-secgw/ipsec-secgw.c:2592:0 For instance, can we guarantee that an application built against DPDK 21.11, but running against 22.xx will never recieve one of the new values in event_desc->subtype (or by any other means)? -- Regards, Ray K