dev.dpdk.org archive mirror
 help / color / mirror / Atom feed
From: "Robin Jarry" <rjarry@redhat.com>
To: "Nitin Saxena" <nsaxena@marvell.com>,
	"dev@dpdk.org" <dev@dpdk.org>, "grout@dpdk.org" <grout@dpdk.org>
Cc: "Jerin Jacob" <jerinj@marvell.com>,
	"David Marchand" <david.marchand@redhat.com>,
	"Christophe Fontaine" <cfontain@redhat.com>,
	"Nitin Saxena" <nsaxena16@gmail.com>
Subject: graph: dispatch mode with libevent for control plane
Date: Mon, 09 Dec 2024 10:27:39 +0100	[thread overview]
Message-ID: <D672A6CZXHPH.XUFCIYI7V0NS@redhat.com> (raw)

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().

https://github.com/DPDK/grout/blob/main/modules/infra/datapath/control_output.c
https://github.com/DPDK/grout/blob/main/modules/infra/control/control_output.c

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


             reply	other threads:[~2024-12-09  9:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-09  9:27 Robin Jarry [this message]
2024-12-16  8:10 ` [EXTERNAL] graph: dispatch mode with libevent for control plane Jerin Jacob

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D672A6CZXHPH.XUFCIYI7V0NS@redhat.com \
    --to=rjarry@redhat.com \
    --cc=cfontain@redhat.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=grout@dpdk.org \
    --cc=jerinj@marvell.com \
    --cc=nsaxena16@gmail.com \
    --cc=nsaxena@marvell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).