From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id DD2D4A0526; Tue, 10 Nov 2020 13:59:51 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A4C312B9D; Tue, 10 Nov 2020 13:59:49 +0100 (CET) Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) by dpdk.org (Postfix) with ESMTP id 3736FF64 for ; Tue, 10 Nov 2020 13:59:48 +0100 (CET) Received: by mail-lf1-f66.google.com with SMTP id i6so17388409lfd.1 for ; Tue, 10 Nov 2020 04:59:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TdUOA3E1z6+nLgBDax7a7INh1lTN02za3UlBx0YFuuQ=; b=ojQWIpXtzeLNGK23o+pExlCpbASMdxF/FVswp2oaaYhntV7Kc6XYPw1JWUbkM/PotL lypTrpoJuwjmsw7UMNxEwgWr3tWOuFcHNUOP2YEPOOxuAdnqwCUOpy6RNnNVKabdCGSb h9roH26n+RtiTZVr9DAaTPiGAljM5S3bVFwYh4yDV2KXyghHx3puwcb0RBJrrqwi+gaU hDkKk/1J3xL1JwUqaFp/sY0wZWP5E7hO0NgAVyviWGvyas5ybvc9wNhm3yo2AcOHEfSf 0grn08yN123oOiZ+RXEWIiY8Ga65eyopRnhI2LK73PQovuvsGK8kgMp5JkG6fywd0Bi5 +mww== X-Gm-Message-State: AOAM531OYHmKgN0LDMkntCx41JxoTmg5X1HWmze1rBvhGRab5YnYPmyF c434rkp6rIPGbT9wJu7VUdC9rUua7ONXEO7ZCHU= X-Google-Smtp-Source: ABdhPJxWEUBuqM3UCFsMYx2h3TNA9wetW+qc3+zTr/Gbhm9qPX4xfAzisgs9pM/TVPCfjTbfAaC36w== X-Received: by 2002:a05:6512:31d6:: with SMTP id j22mr7245302lfe.324.1605013186195; Tue, 10 Nov 2020 04:59:46 -0800 (PST) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com. [209.85.208.177]) by smtp.gmail.com with ESMTPSA id u27sm1809346lfk.47.2020.11.10.04.59.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Nov 2020 04:59:46 -0800 (PST) Received: by mail-lj1-f177.google.com with SMTP id y16so14542573ljk.1 for ; Tue, 10 Nov 2020 04:59:45 -0800 (PST) X-Received: by 2002:a2e:a17c:: with SMTP id u28mr5860787ljl.453.1605013185726; Tue, 10 Nov 2020 04:59:45 -0800 (PST) MIME-Version: 1.0 References: <20200922143202.8755-1-stephen@networkplumber.org> <20201105223602.5965-1-stephen@networkplumber.org> <20201105223602.5965-6-stephen@networkplumber.org> In-Reply-To: <20201105223602.5965-6-stephen@networkplumber.org> From: Luca Boccassi Date: Tue, 10 Nov 2020 12:59:34 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Stephen Hemminger Cc: dev Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v9 5/6] doc: change references to blacklist and whitelist X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, 5 Nov 2020 at 22:36, Stephen Hemminger 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 > Acked-by: Luca Boccassi > --- > 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 > > - .//examples/dpdk-l3fwd -l 0-3 -n 4 -w -- -p 0x3 --eventq-sched=ordered > + .//examples/dpdk-l3fwd -l 0-3 -n 4 -a -- -p 0x3 --eventq-sched=ordered > > or > > .. code-block:: console > > - .//examples/dpdk-l3fwd -l 0-3 -n 4 -w -- -p 0x03 --mode=eventdev --eventq-sched=ordered > + .//examples/dpdk-l3fwd -l 0-3 -n 4 -a \ > + -- -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" ?