> -----Original Message-----
> From: Stephen Hemminger <step...@networkplumber.org>
> Sent: Monday 11 October 2021 23:16
> To: Akhil Goyal <gak...@marvell.com>
> Cc: Thomas Monjalon <tho...@monjalon.net>; dev@dpdk.org;
> david.march...@redhat.com; hemant.agra...@nxp.com; Anoob Joseph
> <ano...@marvell.com>; De Lara Guarch, Pablo
> <pablo.de.lara.gua...@intel.com>; Trahe, Fiona <fiona.tr...@intel.com>;
> Doherty, Declan <declan.dohe...@intel.com>; ma...@nvidia.com;
> g.si...@nxp.com; Zhang, Roy Fan <roy.fan.zh...@intel.com>;
> jianjay.z...@huawei.com; asoma...@amd.com; ruifeng.w...@arm.com;
> Ananyev, Konstantin <konstantin.anan...@intel.com>; Nicolau, Radu
> <radu.nico...@intel.com>; ajit.khapa...@broadcom.com; Nagadheeraj
> Rottela <rnagadhee...@marvell.com>; Ankur Dwivedi
> <adwiv...@marvell.com>; Power, Ciara <ciara.po...@intel.com>; Kinsella,
> Ray <ray.kinse...@intel.com>; Richardson, Bruce
> <bruce.richard...@intel.com>
> Subject: Re: [EXT] Re: [PATCH v2 3/3] security: add reserved bitfields
>
> On Mon, 11 Oct 2021 16:58:24 +0000
> Akhil Goyal <gak...@marvell.com> wrote:
>
> > > 08/10/2021 22:45, Akhil Goyal:
> > > > In struct rte_security_ipsec_sa_options, for every new option
> > > > added, there is an ABI breakage, to avoid, a reserved_opts
> > > > bitfield is added to for the remaining bits available in the
> > > > structure.
> > > > Now for every new sa option, these reserved_opts can be reduced
> > > > and new option can be added.
> > >
> > > How do you make sure this field is initialized to 0?
> > >
> > Struct rte_security_ipsec_xform Is part of rte_security_capability as
> > well As a configuration structure in session create.
> > User, should ensure that if a device support that option(in
> > capability), then only these options will take into effect or else it
> will be don't care for the PMD.
> > The initial values of capabilities are set by PMD statically based on
> > the features that it support.
> > So if someone sets a bit in reserved_opts, it will work only if PMD
> > support it And sets the corresponding field in capabilities.
> > But yes, if a new field is added in future, and user sets the
> > reserved_opts by mistake And the PMD supports that feature as well,
> then that feature will be enabled.
> > This may or may not create issue depending on the feature which is
> enabled.
> >
> > Should I add a note in the comments to clarify that reserved_opts
> > should be set as 0 And future releases may change this without
> notice(But reserved in itself suggest that)?
> > Adding an explicit check in session_create does not make sense to me.
> > What do you suggest?
> >
> > Regards,
> > Akhil
> >
>
> The problem is if user creates an on stack variable and sets the
> unreserved fields to good values but other parts are garbage. This
> passes API/ABI unless you strictly enforce that all reserved fields are
> zero.
Right, but that is no better or worse than the current struct, in that respect,
right?
User case be careless there also - declare it on the stack and forget to memset.
struct rte_security_ipsec_sa_options {
uint32_t esn : 1;
uint32_t udp_encap : 1;
uint32_t copy_dscp : 1;
uint32_t copy_flabel : 1;
uint32_t copy_df : 1;
uint32_t dec_ttl : 1;
uint32_t ecn : 1;
uint32_t stats : 1;
uint32_t iv_gen_disable : 1;
uint32_t tunnel_hdr_verify : 2;
};
