numam-dpdk/lib/timer/version.map

30 lines
466 B
Plaintext
Raw Normal View History

DPDK_22 {
global:
rte_timer_alt_dump_stats;
rte_timer_alt_manage;
rte_timer_alt_reset;
rte_timer_alt_stop;
rte_timer_data_alloc;
rte_timer_data_dealloc;
rte_timer_dump_stats;
rte_timer_init;
rte_timer_manage;
rte_timer_pending;
rte_timer_reset;
rte_timer_reset_sync;
rte_timer_stop;
rte_timer_stop_all;
rte_timer_stop_sync;
rte_timer_subsystem_finalize;
rte_timer_subsystem_init;
local: *;
};
timer: allow management in shared memory Currently, the timer library uses a per-process table of structures to manage skiplists of timers presumably because timers contain arbitrary function pointers whose value may not resolve properly in other processes. However, if the same callback is used handle all timers, and that callback is only invoked in one process, then it woud be safe to allow the data structures to be allocated in shared memory, and to allow secondary processes to modify the timer lists. This would let timers be used in more multi-process scenarios. The library's global variables are wrapped with a struct, and an array of these structures is created in shared memory. The original APIs are updated to reference the zeroth entry in the array. This maintains the original behavior for both primary and secondary processes since the set intersection of their coremasks should be empty [1]. New APIs are introduced to enable the allocation/deallocation of other entries in the array. New variants of the APIs used to start and stop timers are introduced; they allow a caller to specify which array entry should be used to locate the timer list to insert into or delete from. Finally, a new variant of rte_timer_manage() is introduced, which allows a caller to specify which array entry should be used to locate the timer lists to process; it can also process multiple timer lists per invocation. [1] https://doc.dpdk.org/guides/prog_guide/multi_proc_support.html#multi-process-limitations Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
2019-04-15 21:41:27 +00:00
EXPERIMENTAL {
global:
rte_timer_next_ticks;
timer: allow management in shared memory Currently, the timer library uses a per-process table of structures to manage skiplists of timers presumably because timers contain arbitrary function pointers whose value may not resolve properly in other processes. However, if the same callback is used handle all timers, and that callback is only invoked in one process, then it woud be safe to allow the data structures to be allocated in shared memory, and to allow secondary processes to modify the timer lists. This would let timers be used in more multi-process scenarios. The library's global variables are wrapped with a struct, and an array of these structures is created in shared memory. The original APIs are updated to reference the zeroth entry in the array. This maintains the original behavior for both primary and secondary processes since the set intersection of their coremasks should be empty [1]. New APIs are introduced to enable the allocation/deallocation of other entries in the array. New variants of the APIs used to start and stop timers are introduced; they allow a caller to specify which array entry should be used to locate the timer list to insert into or delete from. Finally, a new variant of rte_timer_manage() is introduced, which allows a caller to specify which array entry should be used to locate the timer lists to process; it can also process multiple timer lists per invocation. [1] https://doc.dpdk.org/guides/prog_guide/multi_proc_support.html#multi-process-limitations Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
2019-04-15 21:41:27 +00:00
};