The pathnames in the license directory README are incorrect.
The current repository puts license text in license/ not licenses/.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>
There is an option for recording RSS hash with packets in the
pcapng standard. This implements this for all received packets.
There is a corner case that can not be addressed with current
DPDK API's. If using rte_flow() and some hardware it is possible
to write a flow rule that uses another hash function like XOR.
But there is no API that records this, or provides the algorithm
info on a per-packet basis.
Wireshark recently merged support for displaying the recorded hash
option (for, yet to be released, version 4.1).
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Tested-by: Ben Magistro <koncept1@gmail.com>
When converting atoi to strtol in a revision
of introducing sysfs support for turbo percentage,
a necessary check against '\n' returned by sysfs
was not introduced.
Fixes: de254dac60 ("power: read P-state turbo percentage from sysfs")
Signed-off-by: Markus Theil <markus.theil@secunet.com>
Reviewed-by: Reshma Pattan <reshma.pattan@intel.com>
Allows retrieval of SSO and NPA pffunc addresses without
device ownership and initialization.
Signed-off-by: Jakub Palider <jpalider@marvell.com>
Acked-by: Tomasz Duszynski <tduszynski@marvell.com>
Recent versions of doxygen (1.9.4 and newer) complain about
documented return types for functions that don't return anything.
This patch removes these return types to fix build errors similar
to this one:
[..]
Generating doc/api/doxygen with a custom command
FAILED: doc/api/html
/usr/bin/python3 /path/to/doc/api/generate_doxygen.py doc/api/html
/usr/bin/doxygen doc/api/doxy-api.conf
/root/dpdk/lib/eal/include/rte_bitmap.h:324: error: found documented
return type for rte_bitmap_prefetch0 that does not return anything
(warning treated as error, aborting now)
[..]
Tested with doxygen versions: 1.8.13, 1.8.17, 1.9.1, and 1.9.4.
Signed-off-by: Ali Alnubani <alialnu@nvidia.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
'has_vlan' attribute is only supported by sfc, mlx5 and cnxk.
Other drivers doesn't support it. Most of them (like i40e) just
ignore it silently. Some drivers (like mlx4) never had a full
support of the eth item even before introduction of 'has_vlan'
(mlx4 allows to match on the destination MAC only).
Same for the 'has_more_vlan' flag of the vlan item.
'has_vlan' is part of 'rte_flow_item_eth', so changing 'eth'
field to 'partial support' in documentation for all such drivers.
'has_more_vlan' is part of 'rte_flow_item_vlan', so changing
'vlan' to 'partial support' as well.
This doesn't solve the issue, but at least marks the problematic
drivers.
Some details are available in:
https://bugs.dpdk.org/show_bug.cgi?id=958
Fixes: 09315fc838 ("ethdev: add VLAN attributes to ethernet and VLAN items")
Cc: stable@dpdk.org
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When packet is padded with extra bytes the
the validation of the payload length should be done
after the trim operation
Fixes: b8a55871d5 ("gro: trim tail padding bytes")
Cc: stable@dpdk.org
Signed-off-by: Kumara Parameshwaran <kumaraparamesh92@gmail.com>
Acked-by: Jiayu Hu <jiayu.hu@intel.com>
Fix incorrect expression by cast division operand to type double
to match ceil() and fabs() definitions.
Coverity issue: 381398, 381401, 381402
Fixes: db354bd2e1 ("member: add NitroSketch mode")
Signed-off-by: Leyi Rong <leyi.rong@intel.com>
The cache was still full after flushing. In the opposite direction,
i.e. when getting objects from the cache, the cache is refilled to full
level when it crosses the low watermark (which happens to be zero).
Similarly, the cache should be flushed to empty level when it crosses
the high watermark (which happens to be 1.5 x the size of the cache).
The existing flushing behaviour was suboptimal for real applications,
because crossing the low or high watermark typically happens when the
application is in a state where the number of put/get events are out of
balance, e.g. when absorbing a burst of packets into a QoS queue
(getting more mbufs from the mempool), or when a burst of packets is
trickling out from the QoS queue (putting the mbufs back into the
mempool).
Now, the mempool cache is completely flushed when crossing the flush
threshold, so only the newly put (hot) objects remain in the mempool
cache afterwards.
This bug degraded performance caused by too frequent flushing.
Consider this application scenario:
Either, an lcore thread in the application is in a state of balance,
where it uses the mempool cache within its flush/refill boundaries; in
this situation, the flush method is less important, and this fix is
irrelevant.
Or, an lcore thread in the application is out of balance (either
permanently or temporarily), and mostly gets or puts objects from/to the
mempool. If it mostly puts objects, not flushing all of the objects will
cause more frequent flushing. This is the scenario addressed by this
fix. E.g.:
Cache size=256, flushthresh=384 (1.5x size), initial len=256;
application burst len=32.
If there are "size" objects in the cache after flushing, the cache is
flushed at every 4th burst.
If the cache is flushed completely, the cache is only flushed at every
16th burst.
As you can see, this bug caused the cache to be flushed 4x too
frequently in this example.
And when/if the application thread breaks its pattern of continuously
putting objects, and suddenly starts to get objects instead, it will
either get objects already in the cache, or the get() function will
refill the cache.
The concept of not flushing the cache completely was probably based on
an assumption that it is more likely for an application's lcore thread
to get() after flushing than to put() after flushing.
I strongly disagree with this assumption! If an application thread is
continuously putting so much that it overflows the cache, it is much
more likely to keep putting than it is to start getting. If in doubt,
consider how CPU branch predictors work: When the application has done
something many times consecutively, the branch predictor will expect the
application to do the same again, rather than suddenly do something
else.
Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Reviewed-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
Fix the rte_mempool_do_generic_put() caching flushing algorithm to
keep hot objects in cache instead of cold ones.
The algorithm was:
1. Add the objects to the cache.
2. Anything greater than the cache size (if it crosses the cache flush
threshold) is flushed to the backend.
Please note that the description in the source code said that it kept
"cache min value" objects after flushing, but the function actually kept
the cache full after flushing, which the above description reflects.
Now, the algorithm is:
1. If the objects cannot be added to the cache without crossing the
flush threshold, flush some cached objects to the backend to
free up required space.
2. Add the objects to the cache.
The most recent (hot) objects were flushed, leaving the oldest (cold)
objects in the mempool cache. The bug degraded performance, because
flushing prevented immediate reuse of the (hot) objects already in
the CPU cache. Now, the existing (cold) objects in the mempool cache
are flushed before the new (hot) objects are added the to the mempool
cache.
Since nearby code is touched anyway fix flush threshold comparison
to do flushing if the threshold is really exceed, not just reached.
I.e. it must be "len > flushthresh", not "len >= flushthresh".
Consider a flush multiplier of 1 instead of 1.5; the cache would be
flushed already when reaching size objects, not when exceeding size
objects. In other words, the cache would not be able to hold "size"
objects, which is clearly a bug. The bug could degraded performance
due to premature flushing.
Since we never exceed flush threshold now, cache size in the mempool
may be decreased from RTE_MEMPOOL_CACHE_MAX_SIZE * 3 to
RTE_MEMPOOL_CACHE_MAX_SIZE * 2. In fact it could be
CALC_CACHE_FLUSHTHRESH(RTE_MEMPOOL_CACHE_MAX_SIZE), but flush
threshold multiplier is internal.
Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Reviewed-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
To delete all the queues of an ethdev device associated with
adapter instance the queue_id can be passed as -1 to the queue
delete API.
When a subset of queues of a ethdev device are associated,
the queue delete logic is exiting without deleting the queues
in some cases (higher numbered associated queues) for above
scenario as the queue delete logic is not checking all the
queue association status.
This patch fixes this issue by checking the queue association
status of all the queues of the ethernet device.
Fixes: 741b499e64 ("eventdev/eth_tx: fix queue delete logic")
Cc: stable@dpdk.org
Signed-off-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
Fix the allocation of port COS when the application requested port
COS exceeds (e.g. beyond 0-15) the number of LDB ports for
the domain.
Driver limits application specified ports from a COS to the
max ports allocated for the COS so that the rest of the
ports can be allocated from default(best) COS.
Fixes: bec8901bfe ("event/dlb2: support ldb port specific COS")
Cc: stable@dpdk.org
Signed-off-by: Abdullah Sevincer <abdullah.sevincer@intel.com>
Secondary process is not able to call the crypto adapter
APIs stats get/reset as crypto adapter memzone memory
is not accessible by secondary process.
Added memzone lookup so that secondary process can call the
crypto adapter APIs(stats_get etc)
Fixes: 7901eac340 ("eventdev: add crypto adapter implementation")
Cc: stable@dpdk.org
Signed-off-by: Ganapati Kundapura <ganapati.kundapura@intel.com>
Acked-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
The log should display the value, not the ID.
Fixes: e21df4b062 ("test/eventdev: add SW xstats tests")
Cc: stable@dpdk.org
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
The issue is seen by unit tests:
MALLOC_PERTURB_=204 \
DPDK_TEST=eventdev_selftest_sw \
/root/dpdk/x86_64-native-linuxapp-gcc/app/test/dpdk-test -c 0xff
(...)
*** Running XStats ID Reset test...
12: 1761: qid_0_port_2_pinned_flows value , expected 1 got 7
1778: qid_0_port_2_pinned_flows value incorrect, expected 1 got 7
ERROR - XStats ID Reset test FAILED.
SW Eventdev Selftest Failed.
Test Failed
The flow ID is not set in the event, which results in an undefined
flow, whose value depends on what was previously in stack. Having
different flows for the packets makes the test to fail, since only one
flow is expected.
This only happens in -O3, where the same stack area is shared by the
event object and the address of the mbuf allocated in rte_gen_arp().
Fix this by properly initializing the flow id.
Bugzilla ID: 1101
Fixes: e21df4b062 ("test/eventdev: add SW xstats tests")
Cc: stable@dpdk.org
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
Increase xstats ID width from 32 to 64 bits. This also
fixes the xstats ID datatype discrepancy between reset and
rest of the xstats family.
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Reviewed-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
Fixed release notes for changes made in eventdev library.
Also updated the eventdev guide had got the type of the
rte_event_vector struct's u64s union field wrong.
Fixes: 5fa63911e4 ("eventdev: replace padding type in event vector")
Fixes: 0fbb55efa5 ("eventdev: add element offset to event vector")
Fixes: d986276f9b ("eventdev: add prefix to public symbol")
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
Update the Event Timer Adapter's service function to report as idle
(i.e., return -EAGAIN) in case no timer events were enqueued to the
event device.
Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
Acked-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
Update the Event Ethernet Tx Adapter's service function to report as
idle (i.e., return -EAGAIN) in case no events were dequeued from the
event device and no Ethernet frames were sent out on the wire.
Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
Reviewed-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
Acked-by: Jay Jayatheerthan <jay.jayatheerthan@intel.com>
Update the Event Ethernet Rx Adapter's service function to report as
idle (i.e., return -EAGAIN) in case no Ethernet frames were received
from the ethdev and no events were enqueued to the event device.
Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
Reviewed-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
Acked-by: Jay Jayatheerthan <jay.jayatheerthan@intel.com>
Update the event crypto adapter's service function to report as idle
(i.e., return -EAGAIN) in case no crypto operations were performed.
Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
Acked-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
Fix the calculation error of the total number of LDB ports
during port COS override from dlb2 event structure.
Fixes: bec8901bfe ("event/dlb2: support ldb port specific COS")
Cc: stable@dpdk.org
Signed-off-by: Abdullah Sevincer <abdullah.sevincer@intel.com>
Since COS is now per port specific only and supported through
port_cos in dev_args, there is no need to have a COS
argument in dev_args.
Signed-off-by: Abdullah Sevincer <abdullah.sevincer@intel.com>
Add checks during port probing for validating producer
core masks if they are a subset of EAL coremask.
Error is returned if producer coremask is not a subset
of EAL coremask.
Signed-off-by: Abdullah Sevincer <abdullah.sevincer@intel.com>
Remove COS (class of service) from port probing criteria and
apply enhancements for selection of ports from best
COS when default COS (255) is used.
Signed-off-by: Abdullah Sevincer <abdullah.sevincer@intel.com>
If the socket ID of a device is unknown, rte_eth_dev_socket_id(portid)
now returns -1 instead of 0 since commit 7dcd73e379 ("drivers/bus: set
device NUMA node to unknown by default").
This change breaks the pmd_perf test on environment where the device
socket ID is unknown. The test fails with the following error, because
it does not find a lcore on socket -1:
> No avail lcore to run test
Take the new behavior in account in the pmd_perf test: in this
environment, the test can now run on any lcore, and not only those from
socket 0 (this was the old behavior).
Bugzilla ID: 1105
Fixes: 7dcd73e379 ("drivers/bus: set device NUMA node to unknown by default")
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Tested-by: Lingli Chen <linglix.chen@intel.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
When the dpdk-ioat app was renamed to dpdk-dma this example command
was missed, this patch corrects that issue.
Fixes: bb4141dbe5 ("examples/dma: rename ioat application example")
Signed-off-by: Conor Walsh <conor.walsh@intel.com>
When using dumpcap in container environment or with multiple
DPDK processes, it is useful to be able to specify file prefix.
This version only accepts the long format option used by
other commands. If no prefix is specified then the default
is used.
Suggested-by: Arshdeep Kaur <arshdeep.kaur@intel.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Arshdeep Kaur <arshdeep.kaur@intel.com>
The change to do argument process before EAL init broke
the support of select-interface option. Fix by setting flag
and doing select-interface later.
Fixes: a8dde09f97 ("app/dumpcap: allow help/version without primary process")
Cc: stable@dpdk.org
Signed-off-by: Arshdeep Kaur <arshdeep.kaur@intel.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
When dumpcap is run with a longer path name such as when
testing, the file prefix would be computed incorrectly.
Also, print out the resulting filename which is similar to
what wireshark program does.
Fixes: cbb44143be ("app/dumpcap: add new packet capture application")
Cc: stable@dpdk.org
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
At end of program there is call to rte_free() which is passing
a bogus value. There is no "bpf_filter" defined in this application;
it ends up being a text address inside pcap library.
Fixes: cbb44143be ("app/dumpcap: add new packet capture application")
Cc: stable@dpdk.org
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Assume thread T2 is a service lcore that is in the middle of executing
a service function. Also, assume thread T1 concurrently calls
rte_service_lcore_stop(), which will set the "service_active_on_lcore"
state to false. If thread T1 then calls rte_service_may_be_active(),
it can return zero even though T2 is still running the service function.
If T1 then proceeds to free data being used by T2, a crash can ensue.
Move the logic that clears the "service_active_on_lcore" state from the
rte_service_lcore_stop() function to the service_runner_func() to
ensure that we:
- don't let the "service_active_on_lcore" state linger as 1
- don't clear the state early
Fixes: 6550113be6 ("service: fix lingering active status")
Cc: stable@dpdk.org
Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
Acked-by: Harry van Haaren <harry.van.haaren@intel.com>
Attempts to enable or disable pdump in primary process
will fail with core dump because it is not valid to call
rte_mp_request_sync() unless in a secondary process.
Trap the error in the common code used for both enable
and disable requests.
Fixes: 660098d61f ("pdump: use generic multi-process channel")
Cc: stable@dpdk.org
Reported-by: Sylvia Grundwürmer <sylvia.grundwuermer@b-plus.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Remove arbitrary limit on 12 characters of the file prefix used for the
directory where to store the traces.
Simplify the code by relying on dynamic allocations.
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
Acked-by: Sunil Kumar Kori <skori@marvell.com>
The name of a trace point is provided as a constant string via the
RTE_TRACE_POINT_REGISTER macro.
We can rely on an explicit constant string in the binary and simply point
at it.
There is then no need for a (fixed size) copy.
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
The API does not describe that metadata dump is conditioned to enabling
any trace points.
While at it, merge dump unit tests into the generic trace_autotest to
enhance coverage.
Fixes: f6b2d65dcd ("trace: implement debug dump")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Sunil Kumar Kori <skori@marvell.com>
trace->nb_trace_mem_list access must be under trace->lock to avoid
races with threads allocating/freeing their trace buffers.
Fixes: f6b2d65dcd ("trace: implement debug dump")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
Acked-by: Sunil Kumar Kori <skori@marvell.com>
Enabling trace points at runtime was not working if no trace point had
been enabled first at rte_eal_init() time. The reason was that
trace.args reflected the arguments passed to --trace= EAL option.
To fix this:
- the trace subsystem initialisation is updated: trace directory
creation is deferred to when traces are dumped (to avoid creating
directories that may not be used),
- per lcore memory allocation still relies on rte_trace_is_enabled() but
this helper now tracks if any trace point is enabled. The
documentation is updated accordingly,
- cleanup helpers must always be called in rte_eal_cleanup() since some
trace points might have been enabled and disabled in the lifetime of
the DPDK application,
With this fix, we can update the unit test and check that a trace point
callback is invoked when expected.
Note:
- the 'trace' global variable might be shadowed with the argument
passed to the functions dealing with trace point handles.
'tp' has been used for referring to trace_point object.
Prefer 't' for referring to handles,
Fixes: 84c4fae462 ("trace: implement operation APIs")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Sunil Kumar Kori <skori@marvell.com>
Directly skip the block when a trace point does not match the user
criteria.
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
Acked-by: Sunil Kumar Kori <skori@marvell.com>
The precompiled buffer initialised in regcomp must be freed before
leaving rte_trace_regexp.
Fixes: 84c4fae462 ("trace: implement operation APIs")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
Acked-by: Sunil Kumar Kori <skori@marvell.com>
The API does not state that changing mode should be refused if no trace
point is enabled. Remove this limitation.
Fixes: 84c4fae462 ("trace: implement operation APIs")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Sunil Kumar Kori <skori@marvell.com>
If an application registers trace points later than rte_eal_init(),
changes in the trace point mode were not applied.
Fixes: 84c4fae462 ("trace: implement operation APIs")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
Acked-by: Sunil Kumar Kori <skori@marvell.com>
vdev_probe calls driver->probe and set dev->device.driver,
which will be NULL if the probe fails.
In vdev_cleanup, drv = container_of(dev->device.driver)
drv will be !NULL in this case, causing drv->remove
Segmentation fault.
Fixed by checking dev->device.driver before.
Log:
$ sudo dpdk-test --vdev=crypto_uadk --log-level=6
vdev_probe(): failed to initialize crypto_uadk device
EAL: Bus (vdev) probe failed.
RTE>>quit
Segmentation fault
Fixes: 1cab1a40ea ("bus: cleanup devices on shutdown")
Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Reviewed-by: David Marchand <david.marchand@redhat.com>
During PCI bus device cleanup some interrupt handle pointers and the
bus_info pointer are not being free'd, leading to memory leaks.
This patch fixes the memory leaks by ensuring they are free'd during
device cleanup on exit.
Fixes: 1cab1a40ea ("bus: cleanup devices on shutdown")
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Tested-by: Weiyuan Li <weiyuanx.li@intel.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
Developer tools associated with ABI are maintained with as part of
developer tooling, EAL ABI headers are maintained with EAL,
ABI build scripts are maintained with the build system
and ABI policy and version documents along with rest of the documentation.
Major change is that individual components maintainers become
responsible for ensuring correctness of their map file(s).
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
Try and find the script in the sources of the currently running kernel
so that users do not have to specify DPDK_CHECKPATCH_PATH which might
well be the same location found by the educated guess.
Signed-off-by: Henning Schild <henning.schild@siemens.com>
The method to fetch, sort and read the last entry of a list to figure
out the total number of NUMA nodes in the system fails with 10 or more
nodes. The reason being the usage of string compare while sorting, hence
node 'node10' will be sorted before 'node2'.
Solve this by sorting the list based on integer comparison of the
numerical part of the node name.
Before this change on a system with 16 NUMA nodes,
EAL: Detected CPU lcores: 128
EAL: Detected NUMA nodes: 10
EAL: Static memory layout is selected, amount of reserved memory can
be adjusted with -m or --socket-mem
EAL: Detected static linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'VA'
EAL: VFIO support initialized
With this change on the same system,
EAL: Detected CPU lcores: 128
EAL: Detected NUMA nodes: 16
EAL: Static memory layout is selected, amount of reserved memory can
be adjusted with -m or --socket-mem
EAL: Detected static linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'VA'
EAL: VFIO support initialized
Fixes: 8ef09fdc50 ("build: add optional NUMA and CPU counts detection")
Cc: stable@dpdk.org
Signed-off-by: Peng Zhang <peng.zhang@corigine.com>
Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@corigine.com>
