From: Jerin Jacob <jerinjacobk@gmail.com>
To: "Naga Harish K, S V" <s.v.naga.harish.k@intel.com>
Cc: "jerinj@marvell.com" <jerinj@marvell.com>,
"Carrillo, Erik G" <erik.g.carrillo@intel.com>,
"Gujjar, Abhinandan S" <abhinandan.gujjar@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"Jayatheerthan, Jay" <jay.jayatheerthan@intel.com>
Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
Date: Sat, 28 Jan 2023 16:23:45 +0530 [thread overview]
Message-ID: <CALBAE1PZi7rH3pWmXjQXJmQk==JiCinN7YQzXdxF-0cuS1NxeQ@mail.gmail.com> (raw)
In-Reply-To: <DM6PR11MB38686DA2E1A4332F4B9FF849A1CE9@DM6PR11MB3868.namprd11.prod.outlook.com>
On Wed, Jan 25, 2023 at 10:02 PM Naga Harish K, S V
<s.v.naga.harish.k@intel.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > >
> > > > > > > + */
> > > > > > > + 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.
next prev parent reply other threads:[~2023-01-28 10:54 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-07 16:18 [PATCH " Naga Harish K S V
2023-01-07 16:18 ` [PATCH 2/3] eventdev/eth_tx: " Naga Harish K S V
2023-01-07 16:18 ` [PATCH 3/3] eventdev/crypto: " Naga Harish K S V
2023-01-18 10:22 ` [PATCH 1/3] eventdev/eth_rx: " Jerin Jacob
2023-01-20 8:58 ` Naga Harish K, S V
2023-01-20 9:32 ` Jerin Jacob
2023-01-20 10:33 ` Naga Harish K, S V
2023-01-23 9:31 ` Jerin Jacob
2023-01-23 18:07 ` Naga Harish K, S V
2023-01-23 18:04 ` [PATCH v2 " Naga Harish K S V
2023-01-23 18:04 ` [PATCH v2 2/3] eventdev/eth_tx: " Naga Harish K S V
2023-01-23 18:04 ` [PATCH v2 3/3] eventdev/crypto: " Naga Harish K S V
2023-01-24 4:29 ` [PATCH v2 1/3] eventdev/eth_rx: " Jerin Jacob
2023-01-24 13:07 ` Naga Harish K, S V
2023-01-25 4:12 ` Jerin Jacob
2023-01-25 9:52 ` Naga Harish K, S V
2023-01-25 10:38 ` Jerin Jacob
2023-01-25 16:32 ` Naga Harish K, S V
2023-01-28 10:53 ` Jerin Jacob [this message]
2023-01-28 17:21 ` Stephen Hemminger
2023-01-30 9:56 ` Naga Harish K, S V
2023-01-30 14:43 ` Jerin Jacob
2023-02-02 16:12 ` Naga Harish K, S V
2023-02-03 9:44 ` Jerin Jacob
2023-02-06 6:21 ` Naga Harish K, S V
2023-02-06 16:38 ` Jerin Jacob
2023-02-09 17:00 ` Naga Harish K, S V
2023-02-09 16:57 ` [PATCH v3 " Naga Harish K S V
2023-02-09 16:57 ` [PATCH v3 2/3] eventdev/eth_tx: " Naga Harish K S V
2023-02-09 16:57 ` [PATCH v3 3/3] eventdev/crypto: " Naga Harish K S V
2023-02-10 1:55 ` [PATCH v3 1/3] eventdev/eth_rx: " Naga Harish K S V
2023-02-10 1:55 ` [PATCH v3 2/3] eventdev/eth_tx: " Naga Harish K S V
2023-02-10 1:55 ` [PATCH v3 3/3] eventdev/crypto: " Naga Harish K S V
2023-02-10 4:58 ` [PATCH v4 1/3] eventdev/eth_rx: " Naga Harish K S V
2023-02-10 4:58 ` [PATCH v4 2/3] eventdev/eth_tx: " Naga Harish K S V
2023-02-10 4:58 ` [PATCH v4 3/3] eventdev/crypto: " Naga Harish K S V
2023-02-10 6:30 ` [PATCH v4 1/3] eventdev/eth_rx: " Jerin Jacob
2023-02-10 13:33 ` [PATCH v5 " Naga Harish K S V
2023-02-10 13:33 ` [PATCH v5 2/3] eventdev/eth_tx: " Naga Harish K S V
2023-02-10 13:33 ` [PATCH v5 3/3] eventdev/crypto: " Naga Harish K S V
2023-02-10 13:58 ` [PATCH v5 1/3] eventdev/eth_rx: " Jerin Jacob
2023-02-10 17:42 ` Naga Harish K, S V
2023-02-10 13:46 ` Naga Harish K S V
2023-02-10 13:46 ` [PATCH v5 2/3] eventdev/eth_tx: " Naga Harish K S V
2023-02-10 14:05 ` Jerin Jacob
2023-02-10 15:01 ` Naga Harish K, S V
2023-02-10 15:24 ` Jerin Jacob
2023-02-10 17:41 ` Naga Harish K, S V
2023-02-10 13:46 ` [PATCH v5 3/3] eventdev/crypto: " Naga Harish K S V
2023-02-10 17:37 ` [PATCH v6 1/3] eventdev/eth_rx: " Naga Harish K S V
2023-02-10 17:37 ` [PATCH v6 2/3] eventdev/eth_tx: " Naga Harish K S V
2023-02-10 17:37 ` [PATCH v6 3/3] eventdev/crypto: " Naga Harish K S V
2023-02-13 5:08 ` Jerin Jacob
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALBAE1PZi7rH3pWmXjQXJmQk==JiCinN7YQzXdxF-0cuS1NxeQ@mail.gmail.com' \
--to=jerinjacobk@gmail.com \
--cc=abhinandan.gujjar@intel.com \
--cc=dev@dpdk.org \
--cc=erik.g.carrillo@intel.com \
--cc=jay.jayatheerthan@intel.com \
--cc=jerinj@marvell.com \
--cc=s.v.naga.harish.k@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).