From: "Trahe, Fiona" <fiona.trahe@intel.com>
To: Shally Verma <shallyv@marvell.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "akhil.goyal@nxp.com" <akhil.goyal@nxp.com>,
Ashish Gupta <ashishg@marvell.com>,
"Van Haaren, Harry" <harry.van.haaren@intel.com>,
"Trahe, Fiona" <fiona.trahe@intel.com>
Subject: Re: [dpdk-dev] [PATCH] doc/compressdev: clarify that structs should be zeroed before use
Date: Wed, 28 Aug 2019 10:09:22 +0000 [thread overview]
Message-ID: <348A99DA5F5B7549AA880327E580B435897FA57B@IRSMSX101.ger.corp.intel.com> (raw)
In-Reply-To: <348A99DA5F5B7549AA880327E580B435897FA43E@IRSMSX101.ger.corp.intel.com>
Hi all,
Thanks to feedback from Harry, I've realised that I was only considering applications re-compiled
against the latest DPDK, but without any code rework to use the new feature.
I hadn't considered pre-compiled applications running against shared libs.
This solution is not sufficient to handle those cases.
There are many ways an API may change, this was just one small attempt to
minimise the impact of possible future changes.
So will nack this - we'll just deal with them through the usual
deprecation notices, wrappers, etc if and when they arise.
> > > -----Original Message-----
> > > From: Fiona Trahe <fiona.trahe@intel.com>
> > > Sent: Tuesday, August 27, 2019 10:56 PM
> > > To: dev@dpdk.org
> > > Cc: akhil.goyal@nxp.com; Ashish Gupta <ashishg@marvell.com>; Shally
> > > Verma <shallyv@marvell.com>; Fiona Trahe <fiona.trahe@intel.com>
> > > Subject: [PATCH] doc/compressdev: clarify that structs should be zeroed
> > > before use
> > >
> > > Some structs used on the API are zeroed on creation by API calls, (e.g.
> > > rte_comp_op), but a few are allocated in the application domain.
> > > Clarify that the application should zero those to enable future extensions
> > > without API breakage.
> > >
> > > Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
> > > ---
> > >
doc/guides/prog_guide/compressdev.rst | 10 ++++++++++
> > > 1 files changed, 10 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/doc/guides/prog_guide/compressdev.rst
> > > b/doc/guides/prog_guide/compressdev.rst
> > > index a089db1..2a85eba 100644
> > > --- a/doc/guides/prog_guide/compressdev.rst
> > > +++ b/doc/guides/prog_guide/compressdev.rst
> > > @@ -76,6 +76,11 @@ The ``rte_compressdev_configure`` API is used to
> > > configure a compression device.
> > > The ``rte_compressdev_config`` structure is used to pass the configuration
> > > parameters.
> > >
> > > +The allocation of the ``rte_compressdev_config`` struct passed on the
> > > +API is in the application domain, so to allow future API extensions in
> > > +a backwardly compatible manner the application should zero this struct,
> > > +e.g. using sizeof(), before populating it. This allows the addition of new
> > > parameters to the struct with default value of zero indicating original
> > > behaviour.
> > > +
> > > See *DPDK API Reference* for details.
> > >
> > > Configuration of Queue Pairs
> > > @@ -264,6 +269,11 @@ Compression transforms (``rte_comp_xform``) are
> > > the mechanism to specify the details of the compression operation such as
> > > algorithm, window size and checksum.
> > >
> > > +The allocation of the ``rte_comp_xform`` struct passed on the API is in
> > > +the application domain, so to allow future API extensions in a
> > > +backwardly compatible manner the application should zero this struct,
> > > +e.g. using sizeof(), before populating it. This allows the addition of new
> > > parameters to the struct with default value of zero indicating original
> > > behaviour.
> > > +
> > [Shally] Though summary and description looks fine. Only thing to confirm is that this description is
> > applicable only on xform and config structure? And 0s to all field is allowed values.
> > I have not gone back to refer to latest config and xform structure so take it just a pointer to check on
> > these cases.
> [Fiona] I looked through all API calls and these were the only one I could see. The op, private_xform and
> stream are all handed under the API. But would appreciate a review in case I've missed something.
Nack
prev parent reply other threads:[~2019-08-28 10:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-27 17:26 Fiona Trahe
2019-08-28 4:37 ` Shally Verma
2019-08-28 9:04 ` Trahe, Fiona
2019-08-28 10:09 ` Trahe, Fiona [this message]
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=348A99DA5F5B7549AA880327E580B435897FA57B@IRSMSX101.ger.corp.intel.com \
--to=fiona.trahe@intel.com \
--cc=akhil.goyal@nxp.com \
--cc=ashishg@marvell.com \
--cc=dev@dpdk.org \
--cc=harry.van.haaren@intel.com \
--cc=shallyv@marvell.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).