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 0176E41C23; Mon, 6 Feb 2023 17:38:36 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BAB28427E9; Mon, 6 Feb 2023 17:38:35 +0100 (CET) Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) by mails.dpdk.org (Postfix) with ESMTP id CDFE940ED7 for ; Mon, 6 Feb 2023 17:38:34 +0100 (CET) Received: by mail-vs1-f45.google.com with SMTP id s24so13248583vsi.12 for ; Mon, 06 Feb 2023 08:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=u5/+b8m7MZm4KVUP5BHL5o1sVGq6mqBK0lpPLreSiig=; b=bEccnMANe2pOrtPfux8//ArGVTI65l1skXH4Xka8OtLWkNSsNehyQYTiAmzDE49k7M PLS+ezLp/RpV+jlqo4w5BPTrPCAxhveA6Mahc5m06nrUDjIaOlL7bQuBgNXtfa7vx287 CtJdQ+uexQtQqY3zhOOAiNROZ7n/2rGSGs+4TXsDBHqdbOUzlULGuKuls3WNyFnNLtvf mlljuBrU4CDAcaoBZbqGQ5q5yjLJpr11TbCTnL6ZnO6zv5nezvhQwYhemfIPVuF2qhI9 UmaS7nJqGTAVSLun6KWxnfjg+D/SIqzcax47sKxgsc602vr2lkuQ6ehzmc1fS0lbu6xK a2Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=u5/+b8m7MZm4KVUP5BHL5o1sVGq6mqBK0lpPLreSiig=; b=zQglgisUMCH6iVkXj0hZlJOd8xuw3x6AHAQ5bFo6o+lj8WptgVwJWcscJsGmWFQUoa uXII0NrRWcITb5JVfM0/cjuSkEJG8M+ZjtpD3j6WtBH/8Ps4hYWUa74loIV2RexmPTpN aKW2pWlYuqfXwNaYDr4eCuTDsXmO/gsuS2i6NcPcIeyYCne8ePWrz20VcLflCerKGKe8 8UxseGas2EezrsaWO3n8CABYWchFa4WK4XA7lJj8k7EYTkrsOAwFPgiys3wLje2RClJK cu/rCy1O+eSjOiQzbya4gbOuFnmxVv5hE8K39i83ZVk6DYkhdyS64pP/KJWEM0Rk8zR+ arCg== X-Gm-Message-State: AO0yUKWSxfeTmk5YMEWKN7x9wyDTs/HNm2Zv1uqx65cc9mEb6CKbJWHU 7w7I8ZBQGJbGpHCMM5Xt/VJYGl8PoyU7Jc4JuKE= X-Google-Smtp-Source: AK7set8Fr5luw/yUq+NFNWVzNm8WaQQHNLH00/RgjT324KA2XhzmtoXLtLoi0xoEB3FzX6cN4pGFlxnb7XuOEKCvKjQ= X-Received: by 2002:a67:60c4:0:b0:3f7:fd86:fabf with SMTP id u187-20020a6760c4000000b003f7fd86fabfmr51265vsb.66.1675701514166; Mon, 06 Feb 2023 08:38:34 -0800 (PST) MIME-Version: 1.0 References: <20230107161852.3708690-1-s.v.naga.harish.k@intel.com> <20230123180458.486189-1-s.v.naga.harish.k@intel.com> In-Reply-To: From: Jerin Jacob Date: Mon, 6 Feb 2023 22:08:07 +0530 Message-ID: Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs To: "Naga Harish K, S V" Cc: "jerinj@marvell.com" , "Carrillo, Erik G" , "Gujjar, Abhinandan S" , "dev@dpdk.org" , "Jayatheerthan, Jay" 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 Mon, Feb 6, 2023 at 11:52 AM Naga Harish K, S V wrote: > > Hi Jerin, > > > -----Original Message----- > > From: Jerin Jacob > > Sent: Friday, February 3, 2023 3:15 PM > > To: Naga Harish K, S V > > Cc: jerinj@marvell.com; Carrillo, Erik G ; Gujjar, > > Abhinandan S ; dev@dpdk.org; > > Jayatheerthan, Jay > > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs > > > > On Thu, Feb 2, 2023 at 9:42 PM Naga Harish K, S V > > wrote: > > > > > > Hi Jerin, > > > > > > > -----Original Message----- > > > > From: Jerin Jacob > > > > Sent: Monday, January 30, 2023 8:13 PM > > > > To: Naga Harish K, S V > > > > Cc: jerinj@marvell.com; Carrillo, Erik G > > > > ; Gujjar, Abhinandan S > > > > ; dev@dpdk.org; Jayatheerthan, Jay > > > > > > > > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs > > > > > > > > On Mon, Jan 30, 2023 at 3:26 PM Naga Harish K, S V > > > > wrote: > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Jerin Jacob > > > > > > Sent: Saturday, January 28, 2023 4:24 PM > > > > > > To: Naga Harish K, S V > > > > > > Cc: jerinj@marvell.com; Carrillo, Erik G > > > > > > ; Gujjar, Abhinandan S > > > > > > ; dev@dpdk.org; Jayatheerthan, Jay > > > > > > > > > > > > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get > > > > > > APIs > > > > > > > > > > > > On Wed, Jan 25, 2023 at 10:02 PM Naga Harish K, S V > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Jerin Jacob > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + */ > > > > > > > > > > > > > + uint32_t rsvd[15]; > > > > > > > > > > > > > + /**< Reserved fields for future use */ > > > > > > > > > > > > > > > > > > > > > > > > Introduce > > > > > > > > > > > > rte_event_eth_rx_adapter_runtime_params_init() > > > > > > > > > > > > to > > > > > > > > make > > > > > > > > > > > > sure rsvd is zero. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The reserved fields are not used by the adapter or > > application. > > > > > > > > > > > Not sure Is it necessary to Introduce a new API to > > > > > > > > > > > clear reserved > > > > > > fields. > > > > > > > > > > > > > > > > > > > > When adapter starts using new fileds(when we add new > > > > > > > > > > fieds in future), the old applicaiton which is not using > > > > > > > > > > rte_event_eth_rx_adapter_runtime_params_init() may have > > > > junk > > > > > > > > > > value and then adapter implementation will behave bad. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > does it mean, the application doesn't re-compile for the new > > DPDK? > > > > > > > > > > > > > > > > Yes. No need recompile if ABI not breaking. > > > > > > > > > > > > > > > > > When some of the reserved fields are used in the future, > > > > > > > > > the application > > > > > > > > also may need to be recompiled along with DPDK right? > > > > > > > > > As the application also may need to use the newly consumed > > > > > > > > > reserved > > > > > > > > fields? > > > > > > > > > > > > > > > > The problematic case is: > > > > > > > > > > > > > > > > Adapter implementation of 23.07(Assuming there is change > > > > > > > > params) field needs to work with application of 23.03. > > > > > > > > rte_event_eth_rx_adapter_runtime_params_init() will sove that. > > > > > > > > > > > > > > > > > > > > > > As rte_event_eth_rx_adapter_runtime_params_init() initializes > > > > > > > only > > > > > > reserved fields to zero, it may not solve the issue in this case. > > > > > > > > > > > > rte_event_eth_rx_adapter_runtime_params_init() needs to zero all > > > > > > fields, not just reserved field. > > > > > > The application calling sequence is > > > > > > > > > > > > struct my_config c; > > > > > > rte_event_eth_rx_adapter_runtime_params_init(&c) > > > > > > c.interseted_filed_to_be_updated = val; > > > > > > > > > > > Can it be done like > > > > > struct my_config c = {0}; > > > > > c.interseted_filed_to_be_updated = val; and update Doxygen > > > > > comments to recommend above usage to reset all fields? > > > > > This way, rte_event_eth_rx_adapter_runtime_params_init() can be > > > > avoided. > > > > > > > > Better to have a function for documentation clarity. Similar scheme > > > > already there in DPDK. See rte_eth_cman_config_init() > > > > > > > > > > > > > > > > > The reference function rte_eth_cman_config_init() is resetting the params > > struct and initializing the required params with default values in the pmd cb. > > > > No need for PMD cb. > > > > > The proposed rte_event_eth_rx_adapter_runtime_params_init () API just > > needs to reset the params struct. There are no pmd CBs involved. > > > Having an API just to reset the struct seems overkill. What do you think? > > > > It is slow path API. Keeping it as function is better. Also, it helps the > > documentations of config parm in > > rte_event_eth_rx_adapter_runtime_params_config() > > like, This structure must be initialized with > > rte_event_eth_rx_adapter_runtime_params_init() or so. > > > > > > Are there any other reasons to have this API (*params_init()) other than documentation? Initialization code is segregated for tracking. > > > > > > > > > > > > > > > > > Let me share an example and you can tell where is the issue > > > > > > > > > > > > 1)Assume parameter structure is 64B and for 22.03 8B are used. > > > > > > 2)rte_event_eth_rx_adapter_runtime_params_init() will clear all 64B. > > > > > > 3)There is an application written based on 22.03 which using > > > > > > only 8B after calling > > > > > > rte_event_eth_rx_adapter_runtime_params_init() > > > > > > 4)Assume, in 22.07 another 8B added to structure. > > > > > > 5)Now, the application (3) needs to run on 22.07. Since the > > > > > > application is calling > > > > > > rte_event_eth_rx_adapter_runtime_params_init() > > > > > > and 9 to 15B are zero, the implementation will not go bad. > > > > > > > > > > > > > The old application only tries to set/get previous valid > > > > > > > fields and the newly > > > > > > used fields may still contain junk value. > > > > > > > If the application wants to make use of any the newly used > > > > > > > params, the > > > > > > application changes are required anyway. > > > > > > > > > > > > Yes. If application wants to make use of newly added features. > > > > > > No need to change if new features are not needed for old application.