Dear Chris,
You might look into using the [worker thread] main loop callback mechanism to
schedule a vanilla interior graph node. See
src/vlib/main.c:vlib_main_or_worker(...):
if (PREDICT_FALSE (vec_len (vm->worker_thread_main_loop_callbacks)))
clib_call_callbacks (vm->worker_thread_main_loop_callbacks, vm);
and src/vppinfra/callback.h: clib_callback_enable_disable(...).
In the callback function you can check a deadline timer. If it's not time yet,
return. Otherwise, use vlib_get_frame_to_node(...) /
vlib_put_frame_to_node(...) to allocate a frame to your encap node.
If creating packets out of whole cloth, you might create frame elements in the
callback which are connection indices (or similar) instead of buffer indices.
Or not. You can certainly allocate buffers - or do pretty much anything
dataplane-ish - in a main loop callback.
Check out src/plugins/perfmon for a detailed example which uses both a thread-0
periodic function and main-loop callbacks.
The host stack uses per-worker-thread timer wheels, which might also work for
you.
HTH... Dave
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Christian Hopps
Sent: Monday, August 5, 2019 9:48 AM
To: Dave Barach (dbarach) <[email protected]>
Cc: Christian Hopps <[email protected]>; vpp-dev <[email protected]>
Subject: Re: [vpp-dev] process node's thread
> On Aug 5, 2019, at 9:30 AM, Dave Barach (dbarach) <[email protected]> wrote:
>
> There's nothing inherently magic about thread-0, but one would have to drink
> a certain amount of Kool-Aid in terms of affecting worker-thread performance.
> Topics would include spinning up and servicing timer wheels, placing
> processes on threads, and coding carefully to avoid barrier-sync deadlocks.
>
> What is the use case?
Making something work better for a deliverable before I redesign it. :)
Currently I have a queue of packets to encapsulate many to one per fixed timer
interval. The process is the node which runs on that timer and sends an
encapsulated packet every timer tick (the interval is *very* short). It's
important (for security) that these packets are sent on this fixed interval.
The problem with this running on thread 0 is that other main thread uses (e.g.,
UI, ssh, etc) will cause the packets to not be sent on time (possibly missing
more than a few intervals). I can at least alleviate some of this if I could
place this process on it's own thread on it's own core.
The redesign I have in mind, based on the belief that one can "pin" input nodes
to specific threads, is to switch this output process node to an "input node"
that polls a queue, encapsulating packets that arrive on said queue and sending
the encapsulated packets when the correct time has arrived.
FWIW the actual functionality being developed (plan to contribute back to vpp)
is https://tools.ietf.org/html/draft-hopps-ipsecme-iptfs-01
Thanks,
Chris.
>
> D.
>
> -----Original Message-----
> From: [email protected] <[email protected]> On Behalf Of Christian Hopps
> Sent: Monday, August 5, 2019 9:22 AM
> To: vpp-dev <[email protected]>
> Cc: Christian Hopps <[email protected]>
> Subject: [vpp-dev] process node's thread
>
> Is there a way to have a process node run on a thread other than 0?
>
> Thanks,
> Chris.
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13665): https://lists.fd.io/g/vpp-dev/message/13665
Mute This Topic: https://lists.fd.io/mt/32725233/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
