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 7945E424A7; Sat, 28 Jan 2023 11:54:15 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1D36A40146; Sat, 28 Jan 2023 11:54:15 +0100 (CET) Received: from mail-vk1-f180.google.com (mail-vk1-f180.google.com [209.85.221.180]) by mails.dpdk.org (Postfix) with ESMTP id EAD1C40143 for ; Sat, 28 Jan 2023 11:54:12 +0100 (CET) Received: by mail-vk1-f180.google.com with SMTP id bs10so3614127vkb.3 for ; Sat, 28 Jan 2023 02:54:12 -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=6BtbVJ0Rn6TW08MsVTpuYzXqML+folzeGvXN7Q26CZE=; b=S+hE4y5cHUkDk9G7BNV85PLcwj2tW++H+VNjPdKDG5towbwx10POOS/6rXXKXEuSZt hzOym/PgDjvAZoR8f57fZw2IpxPHfNjZLpAvm75v6joPNvFZHhgGOF/2Oq2xTeeojT4n D9K/AA/+ncCZyyZEXXPAu+PyBxCefipvaJRKLHFHTsfL1Mtef/EwXiBJuHEPY3LqHeK9 7dUtDb3mnwIovNlcm5oNClPx9k3vNjFfdVns2XTJ6fJx0pdX8uHausBCYcWWnO83BCr8 KJooJTs8+159xKYw9NdeZ85E8zwB1WzOncgwihwWj+dkXFc8iV0jSTZOsOuNsfiP2vi/ h+cw== 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=6BtbVJ0Rn6TW08MsVTpuYzXqML+folzeGvXN7Q26CZE=; b=7fM5Jhqd2N0LKJsUNSWNp+ThmoJFDVrIVG8FU1Kbz2JdQwci9pvgz1iQ01oo3sx1Z7 /ET2Qpd5buPWiaHieNtqiatefKk+3HtDTNHYPOLH9oTgUlBDaH6Uw1uoLQbdqx0t1Fml NFxizE4Jj1rTUIo/0BT2sN4rARsSTuEj+CfbB6Td5x56XUmYr+U7meA6zDeuPQyIiLd6 eYQ7adAUo6DFLsVK70LCrLHAmLkWA8R0njJasg6FDIG2U9wnuzE6GxnQKlg0uIOcoFLp TqvWv0jQw3EGI9DNUBmWfKD7DfbG++8p/Ky2lmuLt+6W8LjStZLFFhuFmJaVEWVkW7d3 zynA== X-Gm-Message-State: AFqh2ko/1Dk6NtqcquSacIcOv3bE8+gbrewZTtNhWYTF5SPIEcoieIU7 I9+wT2ydRIBNjUEZGtxEI2+UykB4lJlO9SnBJGk= X-Google-Smtp-Source: AMrXdXteb5dlUGAyQ6ggUtHHWgjRx1Ei1ww5T0SWrOsm1FXJQBqP/4OFxuN5Q1bDTZSTb5DJBjm+kBjHx1K7B/vLFPs= X-Received: by 2002:a05:6122:d9f:b0:3e1:cd5f:ea24 with SMTP id bc31-20020a0561220d9f00b003e1cd5fea24mr4966475vkb.29.1674903252122; Sat, 28 Jan 2023 02:54:12 -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: Sat, 28 Jan 2023 16:23:45 +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 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; 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.