From: Thomas Monjalon
> 09/05/2021 10:31, Matan Azrad:
> >
> > From: Akhil Goyal
> > > > From: Suanming Mou <suanmi...@nvidia.com>
> > > >
> > > > A keytag is a piece of data encrypted together with a DEK.
> > > >
> > > > When a DEK is referenced by an MKEY.bsf through its index, the
> > > > keytag is also supplied in the BSF as plaintext. The HW will
> > > > decrypt the DEK (and the attached keytag) and will fail the
> > > > operation if the keytags don't match.
> > > >
> > > > This commit adds the configuration of the keytag with devargs.
> > > >
> > > > Signed-off-by: Suanming Mou <suanmi...@nvidia.com>
> > > > Signed-off-by: Matan Azrad <ma...@nvidia.com>
> > > > ---
> > > Documentation for devargs should be part of this patch.
> > > Please split the last patch accordingly.
> > >
> > > Title can be shortened to
> > > Crypto/mlx5: add keytag devarg
> > >
> > > Fix other patches of devargs accordingly.
> >
> > As I said before, no devargs is really active before adding datapath
> > patches.
> > The option to add all the supported features \ documentations in the patch
> which actually adds the support is correct.
> >
> > The last patch adds the capabilities and docs when all of them are really
> supported.
>
> I think it is better for git history (blame, etc) to have doc added at the
> same
> time of the code, even if the datapath is not active.
> I agree with Akhil.
User can read the commit log which explain things enough for blame case.
I don't agree, here the devargs has no any usage, just saved in the pmd mem.
The devargs is actually active in the last datapath patch, we can squash the
doc to datapath patch if you realy insist...
