> -----Original Message-----
> From: Robin Jarry <rja...@redhat.com>
> Sent: Monday, December 9, 2024 2:58 PM
> To: Nitin Saxena <nsax...@marvell.com>; dev@dpdk.org; gr...@dpdk.org
> Cc: Jerin Jacob <jer...@marvell.com>; David Marchand
> <david.march...@redhat.com>; Christophe Fontaine <cfont...@redhat.com>;
> Nitin Saxena <nsaxen...@gmail.com>
> Subject: [EXTERNAL] graph: dispatch mode with libevent for control plane
>
> Hi folks, I had a look at the graph dispatch mode and wondered if it could be
> adapted to be used with event loops for "slow path" processing. The use case I
> have in mind is having lcores dedicated for control plane operations which are
> not latency
> Hi folks,
>
> I had a look at the graph dispatch mode and wondered if it could be adapted to
> be used with event loops for "slow path" processing.
>
> The use case I have in mind is having lcores dedicated for control plane
> operations which are not latency sensitive. It would be nice to allow data
> plane
> workers to send packets to these lcores while keeping the packets in the
> graph.
>
> The problem I have with this solution for now, is that all CPUs processing the
> graph with rte_graph_walk_mcore_dispatch() are supposed to do busy polling.
> This is not compatible with select/epoll based event loops.
>
> Would it be possible to have a way for busy-polling threads to signal
> non-busy-
> polling threads that there are packets waiting for them in the graph ring? In
> grout, we implemented something outside of the graph using
> pthread_cond_signal().
Sorry for delay, I was on business travel.
Adding yanzhirun_...@163.com(mcore model maintainer).
If I understand it correctly, we need three operations.
a)wait object creation.
b)wait object waiting instead of polling.
c)signal wait object from fastpath to wake up (b)
I see two options.
Option A:
In application (without graph change)
1)call (a)
2)
while(1)
{
Call (b)
rte_graph_walk_mcore_dispatch()
}
3)Call (c) from fp nodes(Assuming it is out of tree nodes)
Option B
1)Call (a) in model create or so
2)Add an option in rte_graph_walk_mcore_dispatch() to call (b)
3)Update rte_.._enqueue() to call (c) after ring enqueue
Option B is need if we need inbuilt fp nodes.
>
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_DPDK_grout_blob_main_modules_infra_datapath_control-
> 5Foutput.c&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=1DGob4H4rxz6H8uIT
> ozGOCa0s5f4wCNtTa4UUKvcsvI&m=sctQnRalWyQEGrI4o2UpcCXD8n8qveibIe4C
> clcMOUmS7Oi0S7MoVryikpo_ZDh1&s=Zm-
> i7a_D6MFxZO362gYHHe9PtKO_Kr6JeFNlmEHpMCg&e=
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_DPDK_grout_blob_main_modules_infra_control_control-
> 5Foutput.c&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=1DGob4H4rxz6H8uIT
> ozGOCa0s5f4wCNtTa4UUKvcsvI&m=sctQnRalWyQEGrI4o2UpcCXD8n8qveibIe4C
> clcMOUmS7Oi0S7MoVryikpo_ZDh1&s=09ea7Sa47B5SPe7SjP5zBNMzqem0XzI3
> HnlU-k73N2w&e=
>
> Unless I am mistaken, this does not perform any syscall and does not require
> acquiring any lock. Only the "slow" thread needs to acquire locks and wait for
> the data path threads to call pthread_cond_signal().
>
> This solution can only be used for busy-polling -> epoll-based communication,
> for the other direction epoll-based -> busy-polling there would not need any
> specific signaling required. Only posting the packets to the graph ring would
> be
> enough.
>
> What do you think? How would you integrate this into rte_graph? What would
> the API look like in your opinion?
>
> Thanks!
>
> --
> Robin
