On Thu, 5 Nov 2020 at 22:36, Stephen Hemminger
<step...@networkplumber.org> wrote:
>
> There are two areas where documentation needed update.
> The first was use of whitelist when describing address
> filtering.
>
> The other is the legacy -w whitelist option for PCI
> which is used in many examples
>
> Signed-off-by: Stephen Hemminger <step...@networkplumber.org>
> Acked-by: Luca Boccassi <bl...@debian.org>
> ---
> doc/guides/cryptodevs/dpaa2_sec.rst | 6 ++---
> doc/guides/cryptodevs/dpaa_sec.rst | 6 ++---
> doc/guides/cryptodevs/qat.rst | 12 +++++-----
> doc/guides/eventdevs/octeontx2.rst | 20 ++++++++--------
> doc/guides/freebsd_gsg/build_sample_apps.rst | 2 +-
> doc/guides/linux_gsg/build_sample_apps.rst | 2 +-
> doc/guides/linux_gsg/eal_args.include.rst | 14 +++++------
> doc/guides/linux_gsg/linux_drivers.rst | 4 ++--
> doc/guides/mempool/octeontx2.rst | 4 ++--
> doc/guides/nics/bnxt.rst | 18 +++++++--------
> doc/guides/nics/cxgbe.rst | 12 +++++-----
> doc/guides/nics/dpaa.rst | 6 ++---
> doc/guides/nics/dpaa2.rst | 6 ++---
> doc/guides/nics/enic.rst | 6 ++---
> doc/guides/nics/fail_safe.rst | 20 ++++++++--------
> doc/guides/nics/features.rst | 2 +-
> doc/guides/nics/i40e.rst | 16 ++++++-------
> doc/guides/nics/ice.rst | 16 ++++++-------
> doc/guides/nics/ixgbe.rst | 4 ++--
> doc/guides/nics/mlx4.rst | 18 +++++++--------
> doc/guides/nics/mlx5.rst | 14 +++++------
> doc/guides/nics/nfb.rst | 2 +-
> doc/guides/nics/octeontx2.rst | 23 ++++++++++---------
> doc/guides/nics/sfc_efx.rst | 2 +-
> doc/guides/nics/tap.rst | 2 +-
> doc/guides/nics/thunderx.rst | 4 ++--
> .../prog_guide/env_abstraction_layer.rst | 8 +++----
> doc/guides/prog_guide/multi_proc_support.rst | 4 ++--
> doc/guides/prog_guide/poll_mode_drv.rst | 6 ++---
> .../prog_guide/switch_representation.rst | 6 ++---
> doc/guides/sample_app_ug/bbdev_app.rst | 14 +++++------
> .../sample_app_ug/eventdev_pipeline.rst | 4 ++--
> doc/guides/sample_app_ug/ipsec_secgw.rst | 12 +++++-----
> doc/guides/sample_app_ug/l3_forward.rst | 7 +++---
> .../sample_app_ug/l3_forward_access_ctrl.rst | 2 +-
> .../sample_app_ug/l3_forward_power_man.rst | 3 ++-
> doc/guides/sample_app_ug/vdpa.rst | 2 +-
> doc/guides/tools/cryptoperf.rst | 6 ++---
> doc/guides/tools/flow-perf.rst | 2 +-
> doc/guides/tools/testregex.rst | 2 +-
> 40 files changed, 161 insertions(+), 158 deletions(-)
<..>
> diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
> index c408ab71385b..33832ad2a1d8 100644
> --- a/doc/guides/nics/mlx4.rst
> +++ b/doc/guides/nics/mlx4.rst
> @@ -24,8 +24,8 @@ Most Mellanox ConnectX-3 devices provide two ports but
> expose a single PCI
> bus address, thus unlike most drivers, librte_net_mlx4 registers itself as a
> PCI driver that allocates one Ethernet device per detected port.
>
> -For this reason, one cannot white/blacklist a single port without also
> -white/blacklisting the others on the same device.
> +For this reason, one cannot use block (or allow) a single port without also
> +blocking (o allowing) the others on the same device.
Perhaps "one cannot use block" -> "one cannot block" reads better?
> Besides its dependency on libibverbs (that implies libmlx4 and associated
> kernel support), librte_net_mlx4 relies heavily on system calls for control
> @@ -381,7 +381,7 @@ devices managed by librte_net_mlx4.
> eth4
> eth5
>
> -#. Optionally, retrieve their PCI bus addresses for whitelisting::
> +#. Optionally, retrieve their PCI bus addresses for use in allow argument::
"for use in" -> "to be used with the" ?
> {
> for intf in eth2 eth3 eth4 eth5;
> @@ -389,14 +389,14 @@ devices managed by librte_net_mlx4.
> (cd "/sys/class/net/${intf}/device/" && pwd -P);
> done;
> } |
> - sed -n 's,.*/\(.*\),-w \1,p'
> + sed -n 's,.*/\(.*\),-a \1,p'
>
> Example output::
>
> - -w 0000:83:00.0
> - -w 0000:83:00.0
> - -w 0000:84:00.0
> - -w 0000:84:00.0
> + -a 0000:83:00.0
> + -a 0000:83:00.0
> + -a 0000:84:00.0
> + -a 0000:84:00.0
>
> .. note::
>
> @@ -409,7 +409,7 @@ devices managed by librte_net_mlx4.
>
> #. Start testpmd with basic parameters::
>
> - testpmd -l 8-15 -n 4 -w 0000:83:00.0 -w 0000:84:00.0 -- --rxq=2
> --txq=2 -i
> + testpmd -l 8-15 -n 4 -a 0000:83:00.0 -a 0000:84:00.0 -- --rxq=2
> --txq=2 -i
>
> Example output::
>
> diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
> index 59b2bf4036b9..d988e887f345 100644
> --- a/doc/guides/nics/mlx5.rst
> +++ b/doc/guides/nics/mlx5.rst
> @@ -1524,7 +1524,7 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices
> managed by librte_net_mlx5.
> eth32
> eth33
>
> -#. Optionally, retrieve their PCI bus addresses for whitelisting::
> +#. Optionally, retrieve their PCI bus addresses for use in allow list::
Same question as above
<..>
> diff --git a/doc/guides/prog_guide/multi_proc_support.rst
> b/doc/guides/prog_guide/multi_proc_support.rst
> index a84083b96c8a..29bc83f4365f 100644
> --- a/doc/guides/prog_guide/multi_proc_support.rst
> +++ b/doc/guides/prog_guide/multi_proc_support.rst
> @@ -30,7 +30,7 @@ after a primary process has already configured the hugepage
> shared memory for th
> Secondary processes should run alongside primary process with same DPDK
> version.
>
> Secondary processes which requires access to physical devices in Primary
> process, must
> - be passed with the same whitelist and blacklist options.
> + be passed with the same allow and block options.
>
> To support these two process types, and other multi-process setups described
> later,
> two additional command-line parameters are available to the EAL:
> @@ -131,7 +131,7 @@ can use).
> .. note::
>
> Independent DPDK instances running side-by-side on a single machine
> cannot share any network ports.
> - Any network ports being used by one process should be blacklisted in
> every other process.
> + Any network ports being used by one process should be added to block
> list in every other process.
"added to the block list"
<..>
> diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst
> b/doc/guides/sample_app_ug/ipsec_secgw.rst
> index 1f37dccf8bb7..cb637abdfaf4 100644
> --- a/doc/guides/sample_app_ug/ipsec_secgw.rst
> +++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
> @@ -323,15 +323,15 @@ This means that if the application is using a single
> core and both hardware
> and software crypto devices are detected, hardware devices will be used.
>
> A way to achieve the case where you want to force the use of virtual crypto
> -devices is to whitelist the Ethernet devices needed and therefore implicitly
> -blacklisting all hardware crypto devices.
> +devices is to allowed the Ethernet devices needed and therefore implicitly
> +blocklisting all hardware crypto devices.
"to allowed" -> "to allow"
<..>
> diff --git a/doc/guides/sample_app_ug/l3_forward.rst
> b/doc/guides/sample_app_ug/l3_forward.rst
> index 7acbd7404e3b..5d53bf633db7 100644
> --- a/doc/guides/sample_app_ug/l3_forward.rst
> +++ b/doc/guides/sample_app_ug/l3_forward.rst
> @@ -138,17 +138,18 @@ Following is the sample command:
>
> .. code-block:: console
>
> - ./<build_dir>/examples/dpdk-l3fwd -l 0-3 -n 4 -w <event device> -- -p
> 0x3 --eventq-sched=ordered
> + ./<build_dir>/examples/dpdk-l3fwd -l 0-3 -n 4 -a <event device> -- -p
> 0x3 --eventq-sched=ordered
>
> or
>
> .. code-block:: console
>
> - ./<build_dir>/examples/dpdk-l3fwd -l 0-3 -n 4 -w <event device> -- -p
> 0x03 --mode=eventdev --eventq-sched=ordered
> + ./<build_dir>/examples/dpdk-l3fwd -l 0-3 -n 4 -a <event device> \
> + -- -p 0x03 --mode=eventdev --eventq-sched=ordered
>
> In this command:
>
> -* -w option whitelist the event device supported by platform. Way to pass
> this device may vary based on platform.
> +* -a option adds the event device supported by platform. Way to pass this
> device may vary based on platform.
"adds" -> "allows" ?
