Similarly replace PCI_BLACKLIST with PCI_BLOCKED.
Use of ALLOWED/BLOCKED matches similar changes made
in DPDK.
While here, replace use of term "blacklist" with "blocked"
in one of the nvme perf scripts. The usage there was
associated with how devices are blocked by using the
environment variables that are changed by this patch.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I720d99118ba5e050f436612c9fd415db44294a63
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/5275
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Community-CI: Mellanox Build Bot
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
It could potentially override cmp binary, causing failures in some
of the tests.
Change-Id: Ia0bd88222c60e5b8a13d3809a6213b457b887b41
Signed-off-by: Michal Berger <michalx.berger@intel.com>
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/5005
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
If devices are not picked up from the cache, iter_all_pci_class_code()
will pick lspci in first instance to iterate over the pci bus. If said
tool is installed on FreeBSD, it will return BDFs in format which won't
be understood by pciconf (which is used to determine which driver given
device is bound to):
pciconf: cannot parse selector pci0000:00:06.0
To make sure pciconf understands the argument it's given, simply
replace .function with :function (0000:00:06.0 -> 0000:00:06:0).
Change-Id: I59d4f7050c65df99626a3d449aa0a5bb122d4081
Signed-off-by: Michal Berger <michalx.berger@intel.com>
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/4665
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
On its own these values don't uniquely identify a particular pci
device, hence there's no much point in storing them like so.
Change-Id: Icc5cfec28fcccae6cd935dff03fe3ef01826edc4
Signed-off-by: Michal Berger <michalx.berger@intel.com>
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/3950
Community-CI: Mellanox Build Bot
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Check if given pci address is bound to nvme driver via a separate
function - this makes the task of getting list of the nvme devices
that can be used in tests a bit easier since we don't have to relay
on, e.g., gen_nvme.sh where the extra step to get said devices is
to parse the actual config.
Change-Id: I1f15f08a3678c0c41b051348af259e225356c340
Signed-off-by: Michal Berger <michalx.berger@intel.com>
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/3014
Community-CI: Mellanox Build Bot
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
Expose a cache of pci devices in form of an assoc array that could be
looked up during the runtime of a script like setup.sh.
In case of setup.sh, caching speeds up execution quite visibly:
config run, no caching:
real 0m4.488s
user 0m1.440s
sys 0m1.260s
config run, caching in use:
real 0m2.876s
user 0m0.365s
sys 0m0.420s
Note that for initial config runs, binding controllers to proper
drivers is the actual bottleneck.
status run, no caching:
real 0m1.877s
user 0m1.252s
sys 0m0.984s
status run, caching in use:
real 0m0.371s
user 0m0.242s
sys 0m0.204s
reset run, no caching:
real 0m2.559s
user 0m1.409s
sys 0m1.322s
reset run, caching in use:
real 0m0.960s
user 0m0.432s
sys 0m0.419s
Additionally, in case common tools, e.g. lspci, are missing, fallback to
sysfs to pick all needed devices from the pci bus. Targeted for Linux
systems only.
Change-Id: Ib69ef724b9f09eca0cbb9b88f1c363edc1efd5dc
Signed-off-by: Michal Berger <michalx.berger@intel.com>
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/1845
Community-CI: Mellanox Build Bot
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
Error msg in common.sh should be printed into stderr
in order to avoid improper usage.
For example:
If env has no lspci and pciconf, then function
iter_all_pci_class_code will return the error msg back,
every word in error msg will be used by caller wrongly.
Change-Id: I6a875e49527539ba82bd331c8878e972e26cbc39
Signed-off-by: Liu Xiaodong <xiaodong.liu@intel.com>
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/1227
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Aleksey Marchuk <alexeymar@mellanox.com>
iter_pci_dev_id abd iter_pci_dev_id functions should
not return BDF for devices that are not ment to be used
in tests.
Note that not all tests are ready for this change as they
discover functions on its own. Lets this changed in
separate patch.
Change-Id: I45a59ec121aa81e9f981acae7ec0379ff68e520a
Signed-off-by: Pawel Wodkowski <pawelx.wodkowski@intel.com>
Reviewed-on: https://review.gerrithub.io/c/443767
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com>
Add a new file, scripts/common.sh, that can be shared between not only
autotest scripts, but also scripts/setup.sh, scripts/gen_nvme.sh, etc.,
and move the PCI iteration functions there.
The iterators are also expanded to work identically for both dev_id and
class_code on Linux and FreeBSD.
Change-Id: I98423cd06242e78535f5da4fce82166812ea96a8
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-on: https://review.gerrithub.io/393416
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
