On Wed, 15 Jul 2020 16:02:57 -0700 Stephen Hemminger <step...@networkplumber.org> wrote:
> diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst > index 7f4036c3210e..38e5b0a96206 100644 > --- a/doc/guides/cryptodevs/qat.rst > +++ b/doc/guides/cryptodevs/qat.rst > @@ -126,7 +126,7 @@ Limitations > optimisations in the GEN3 device. And if a GCM session is initialised on a > GEN3 device, then attached to an op sent to a GEN1/GEN2 device, it will > not be > enqueued to the device and will be marked as failed. The simplest way to > - mitigate this is to use the bdf whitelist to avoid mixing devices of > different > + mitigate this is to use the bdf allowlist to avoid mixing devices of > different > generations in the same process if planning to use for GCM. > * The mixed algo feature on GEN2 is not supported by all kernel drivers. > Check > the notes under the Available Kernel Drivers table below for specific > details. > @@ -261,7 +261,7 @@ adjusted to the number of VFs which the QAT common code > will need to handle. > QAT VF may expose two crypto devices, sym and asym, it may happen > that the > number of devices will be bigger than MAX_DEVS and the process will > show an error > during PMD initialisation. To avoid this problem > CONFIG_RTE_CRYPTO_MAX_DEVS may be > - increased or -w, pci-whitelist domain:bus:devid:func option may be > used. > + increased or -w, pci-allowlist domain:bus:devid:func option may be > used. Looks like this got muddled in all the edits, will resend.