> Allow driver configuration via environment variables as a fallback > when devargs are not provided. After processing devargs (or when > devargs are absent), check DRIVER_STRICT_ORDER and DRIVER_DUMP_MODE > environment variables to set en_loose_ordered and dpaa2_sec_dp_dump. > > This lets users configure the driver without modifying EAL arguments, > useful in environments where command-line access is restricted. > > Signed-off-by: Gagandeep Singh <[email protected]> > --- > doc/guides/cryptodevs/dpaa2_sec.rst | 12 ++++++++- > drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 27 ++++++++++++++++++--- > 2 files changed, 34 insertions(+), 5 deletions(-) > > diff --git a/doc/guides/cryptodevs/dpaa2_sec.rst > b/doc/guides/cryptodevs/dpaa2_sec.rst > index f95c6282bb..925d3371bf 100644 > --- a/doc/guides/cryptodevs/dpaa2_sec.rst > +++ b/doc/guides/cryptodevs/dpaa2_sec.rst > @@ -1,5 +1,5 @@ > .. SPDX-License-Identifier: BSD-3-Clause > - Copyright 2016 NXP > + Copyright 2016,2026 NXP > > > > @@ -188,9 +188,19 @@ along with other useful debugging information like > session, queue, descriptor > data. > e.g. ``fslmc:dpseci.1,drv_dump_mode=1`` > > +Alternatively, set the environment variable ``drv_dump_mode`` to the desired > +mode value. The environment variable is used as a fallback when the devarg is > +not provided, which is useful in production environments where modifying EAL > +command-line arguments is not practical. > +e.g. ``export drv_dump_mode=1`` > +
I think Stephen has pointed out that this is bad precedent. DPDK has already a way to configure to avoid env variables. It is not clear why we need this? While there is a way to set env variable, but cannot change command line args? Is this a debug thing?
