| /dpdk/examples/service_cores/ |
| H A D | main.c | 65 struct profile_for_core cores[PROFILE_CORES_MAX]; member
73 .cores[0] = {.mapped_services = {1, 0, 0, 0, 0} },
74 .cores[1] = {.mapped_services = {0, 1, 0, 0, 0} },
75 .cores[2] = {.mapped_services = {0, 0, 1, 0, 0} },
76 .cores[3] = {.mapped_services = {0, 0, 0, 1, 0} },
77 .cores[4] = {.mapped_services = {0, 0, 0, 0, 1} },
83 .cores[0] = {.mapped_services = {1, 1, 0, 0, 0} },
84 .cores[1] = {.mapped_services = {0, 0, 1, 1, 0} },
85 .cores[2] = {.mapped_services = {0, 0, 0, 0, 1} },
86 .cores[3] = {.mapped_services = {0, 0, 0, 0, 0} },
[all …]
|
| /dpdk/app/test/ |
| H A D | test_stack_perf.c | 181 if (cores->c1 == rte_get_main_lcore()) { in run_on_core_pair()
184 rte_eal_wait_lcore(cores->c2); in run_on_core_pair()
188 rte_eal_wait_lcore(cores->c1); in run_on_core_pair()
189 rte_eal_wait_lcore(cores->c2); in run_on_core_pair()
300 struct lcore_pair cores; in __test_stack_perf() local
321 if (get_two_hyperthreads(&cores) == 0) { in __test_stack_perf()
323 run_on_core_pair(&cores, s, bulk_push_pop); in __test_stack_perf()
325 if (get_two_cores(&cores) == 0) { in __test_stack_perf()
327 run_on_core_pair(&cores, s, bulk_push_pop); in __test_stack_perf()
329 if (get_two_sockets(&cores) == 0) { in __test_stack_perf()
[all …]
|
| H A D | test_mempool_perf.c | 229 launch_cores(struct rte_mempool *mp, unsigned int cores) in launch_cores() argument
234 unsigned cores_save = cores; in launch_cores()
245 cores, n_get_bulk, n_put_bulk, n_keep, use_constant_values); in launch_cores()
253 if (cores == 1) in launch_cores()
255 cores--; in launch_cores()
265 cores = cores_save; in launch_cores()
267 if (cores == 1) in launch_cores()
269 cores--; in launch_cores()
290 do_one_mempool_test(struct rte_mempool *mp, unsigned int cores) in do_one_mempool_test() argument
308 ret = launch_cores(mp, cores); in do_one_mempool_test()
[all …]
|
| H A D | test_ring_perf.c | 300 if (cores->c1 == rte_get_main_lcore()) { in run_on_core_pair()
303 rte_eal_wait_lcore(cores->c2); in run_on_core_pair()
307 if (rte_eal_wait_lcore(cores->c1) < 0) in run_on_core_pair()
309 if (rte_eal_wait_lcore(cores->c2) < 0) in run_on_core_pair()
497 struct lcore_pair cores; in test_ring_perf_esize() local
538 if (get_two_hyperthreads(&cores) == 0) { in test_ring_perf_esize()
540 if (run_on_core_pair(&cores, r, esize) < 0) in test_ring_perf_esize()
544 if (get_two_cores(&cores) == 0) { in test_ring_perf_esize()
546 if (run_on_core_pair(&cores, r, esize) < 0) in test_ring_perf_esize()
549 if (get_two_sockets(&cores) == 0) { in test_ring_perf_esize()
[all …]
|
| H A D | test_func_reentrancy.c | 435 unsigned int cores; in launch_test() local
445 cores = RTE_MIN(rte_lcore_count(), MAX_LCORES); in launch_test()
447 if (cores == 1) in launch_test()
449 cores--; in launch_test()
|
| /dpdk/doc/guides/prog_guide/ |
| H A D | service_cores.rst | 7 DPDK has a concept known as service cores, which enables a dynamic way of
10 cores are used at runtime.
12 The service cores concept is built up out of services (components of DPDK that
13 require CPU cycles to operate) and service cores (DPDK lcores, tasked with
15 between service cores and services can be configured to abstract away the
20 PMD does not. With service cores, the application would not directly notice
28 There are two methods to having service cores in a DPDK application, either by
29 using the service coremask, or by dynamically adding cores using the API.
32 in the service coremask the cores become service-cores instead of DPDK
39 service cores. Enabling a service on a particular core means that the lcore in
[all …]
|
| H A D | meson_ut.rst | 42 For example, tests will by default run on as many available cores as is needed
44 To run the fast-tests suite using only cores 8 through 16, one can use::
81 #. Not enough processing cores. Some tests are skipped on machines with 2 or 4 cores.
|
| H A D | packet_distrib_lib.rst | 9 When using this library, the logical cores in use are to be considered in two roles: firstly a dist…
58 It returns to the caller all packets which have finished processing by all worker cores.
87 Worker cores are the cores which do the actual manipulation of the packets distributed by the packe…
91 Since it may be desirable to vary the number of worker cores, depending on the traffic load
|
| /dpdk/usertools/ |
| H A D | cpu_layout.py | 7 cores = [] variable
23 if core not in cores:
24 cores.append(core)
35 print("cores = ", cores)
39 max_processor_len = len(str(len(cores) * len(sockets) * 2 - 1))
44 max_core_id_len = len(str(max(cores)))
57 for c in cores:
|
| /dpdk/doc/guides/sample_app_ug/ |
| H A D | service_cores.rst | 7 The service cores sample application demonstrates the service cores capabilities
8 of DPDK. The service cores infrastructure is part of the DPDK EAL, and allows
15 service cores APIs, however the sample application introduces a "profile"
17 is application specific, and not a part of the service cores API.
31 adds service cores in the application code itself, there is no requirement to
53 to the ordinary service cores header ``rte_service.h`` which provides
54 the runtime functions to add, remove and remap service cores.
67 header file provides the functions for dynamically adding and removing cores.
68 The APIs to add and remove cores use lcore IDs similar to existing DPDK
91 The service cores infrastructure provides DPDK with two main features. The first
|
| H A D | packet_ordering.rst | 13 The application uses at least three CPU cores:
16 cores with traffic through SW queues.
22 * TX Core (worker core) receives traffic from Worker cores through software queues,
49 The -c EAL CPU_COREMASK option has to contain at least 3 CPU cores.
51 RX core, the last to TX core and the rest to Worker cores.
|
| H A D | keep_alive.rst | 8 heartbeat/watchdog for packet processing cores. It demonstrates how
9 to detect 'failed' DPDK cores and notify a fault management entity
19 on packet processing cores. A Keep Alive Monitor Agent Core (main)
20 monitors the state of packet processing cores (worker cores) by
22 monitoring the state of the cores. Cores states are: Alive, MIA, Dead
30 Note: Only the worker cores are monitored. A local (on the host) mechanism
|
| H A D | dist_app.rst | 8 to cores using the Data Plane Development Kit (DPDK). It also makes use of
16 on an RX_PORT to different cores. When processed by the cores, the destination
110 Intel-SST-BF, a technology that allows some cores to run at a higher
116 frequency SST-BF cores, and when starting the application, if high frequency
117 SST-BF cores are present in the core mask, the application will identify these
118 cores and pin the workloads appropriately. The distributor core is usually
120 cores, followed by the rx core and the tx core.
|
| H A D | eventdev_pipeline.rst | 9 application can configure a pipeline and assign a set of worker cores to
13 configured for various numbers worker cores, stages,queue depths and cycles per
41 * ``-w FF00``: core mask for worker cores, 8 cores from 8th to 16th
59 Core part of pipeline was not assigned any cores. This will stall the
117 transmitted, and an overview of the distribution of work across worker cores.
|
| H A D | vm_power_management.rst | 410 ``--core-branch-ratio {list of cores}:{branch ratio for listed cores}``
515 run on cores 0, 1, 2 and 3:
534 ``--vcpu-list {list vm cores}``
535 A comma-separated list of cores in the VM that the user
537 The list of cores in any VM starts at zero,
540 Valid syntax includes individual cores 2,3,4,
600 of the specified cores in the policy.
714 of the specified cores in the policy.
793 The cores to which to apply a policy.
861 Scale the frequencies of the relevant cores up/down
[all …]
|
| H A D | l3_forward_graph.rst | 62 …,lcore)[,(port,queue,lcore)]:`` Determines which queues from which ports are mapped to which cores.
72 For example, consider a dual processor socket platform with 8 physical cores, where cores 0-7 and 1…
73 while cores 8-15 and 24-31 appear on socket 1.
75 …between two ports, assuming that both ports are in the same socket, using two cores, cores 1 and 2,
84 * The -l option enables cores 1, 2
|
| /dpdk/examples/vm_power_manager/guest_cli/ |
| H A D | main.c | 54 unsigned short int cores[RTE_POWER_MAX_VCPU_PER_VM]; in parse_args() local
102 cnt = parse_set(optarg, cores, in parse_args()
111 if (cores[i]) { in parse_args()
|
| /dpdk/doc/guides/cryptodevs/ |
| H A D | scheduler.rst | 154 worker cores. The enqueued bursts are distributed among the worker cores in a
159 For mixed traffic (IMIX) the optimal number of worker cores is around 2-3.
161 up to eight cores.
167 * corelist: Semicolon-separated list of logical cores to be used as workers.
168 The number of worker cores should be equal to the number of worker cryptodevs.
169 These cores should be present in EAL core list parameter and
|
| /dpdk/doc/guides/tools/ |
| H A D | testregex.rst | 16 By default the test supports one QP per core, however a higher number of cores
17 and QPs can be configured. The QPs are evenly distributed on the cores. All QPs
63 number of cores to use
|
| H A D | comp_perf.rst | 9 compress tree. User can use multiple cores to run tests on but only
48 Set the hexadecimal bitmask of the cores to run on. The corelist is a
49 list cores to use.
53 One lcore is needed for process admin, tests are run on all other cores.
|
| /dpdk/lib/eal/windows/ |
| H A D | eal_lcore.c | 114 const GROUP_AFFINITY *cores = &info->NumaNode.GroupMask; in eal_create_lcore_map() local
138 if ((cores->Mask & ((KAFFINITY)1 << i)) == 0) in eal_create_lcore_map()
146 lcore->core_id = cores->Group * EAL_PROCESSOR_GROUP_SIZE + i; in eal_create_lcore_map()
|
| /dpdk/doc/guides/linux_gsg/ |
| H A D | build_sample_apps.rst | 43 An hexadecimal bit mask of the cores to run on. Note that core numbering can
115 and that cores 0-3 are present and are to be used for running the application)::
130 …as reported by Linux. The preferred corelist option is a cleaner method to define cores to be used.
131 Since these logical core numbers, and their mapping to specific cores on specific NUMA sockets, can…
134 On initialization of the EAL layer by a DPDK application, the logical cores to be used and their so…
135 This information can also be determined for all cores on the system by examining the ``/proc/cpuinf…
137 This can be useful when using other processors to understand the mapping of the logical cores to th…
|
| /dpdk/doc/guides/howto/ |
| H A D | pvp_reference_benchmark.rst | 30 requires 6 dedicated logical cores. A forwarding configuration with a single
31 NIC is also possible, requiring 3 logical cores.
37 In this setup, we isolate 6 cores (from CPU2 to CPU7) on the same NUMA
38 node. Two cores are assigned to the VM vCPUs running testpmd and four are
129 --nb-cores=4 --forward-mode=io
246 <topology sockets='1' cores='3' threads='1'/>
339 --rxd=256 --txd=256 --nb-cores=2 --auto-start
|
| H A D | debug_troubleshoot.rst | 34 primary process, with various processing stages running on multiple cores. The
36 cores, mempool, mbuf, eventdev, cryptodev, QoS, and ethdev.
110 RX-TX port and associated cores :numref:`dtg_rx_tx_drop`.
257 * Ensure cryptodev, resources and enqueue is running on NUMA cores.
265 * Ensure cryptodev, resources and dequeue are running on NUMA cores.
299 * The functions running on CPU cores without context switches are the
310 cores.
324 service functions on service cores :numref:`dtg_service`.
330 functions running on service cores
338 * A service to run parallel on all cores should return
|
| /dpdk/examples/vmdq_dcb/ |
| H A D | main.c | 639 unsigned cores; in main() local
661 cores = rte_lcore_count(); in main()
662 if ((cores & (cores - 1)) != 0 || cores > RTE_MAX_LCORE) { in main()
|