From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Gavin Hu <Gavin.Hu@arm.com>,
nd <nd@arm.com>, Hemant Agrawal <hemant.agrawal@nxp.com>
Subject: Re: [dpdk-dev] [RFC] queue: introduce queue APIs and driver framework
Date: Mon, 16 Jul 2018 02:51:18 +0000 [thread overview]
Message-ID: <HE1PR0801MB19305DD6F2AA0467C1C1BE64985D0@HE1PR0801MB1930.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <20180711065122.GA20799@jerin>
> -----Original Message-----
> From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> Sent: Wednesday, June 27, 2018 11:20 AM
> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Cc: dev@dpdk.org; Gavin Hu <Gavin.Hu@arm.com>; nd <nd@arm.com>
> Subject: Re: [dpdk-dev] [RFC] queue: introduce queue APIs and driver
> framework
>
> -----Original Message-----
> > Date: Wed, 27 Jun 2018 11:06:13 -0500
> > From: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > To: dev@dpdk.org
> > CC: honnappa.nagarahalli@arm.com, gavin.hu@arm.com, nd@arm.com
> > Subject: [dpdk-dev] [RFC] queue: introduce queue APIs and driver
> > framework
> > X-Mailer: git-send-email 2.7.4
> >
> >
> > DPDK offers pipeline model of packet processing. One of the key
> > components of this model is the core to core packet exchange.
> > rte_ring and rte_event_ring functions are 2 methods provided
> > currently for core to core communication. However, these two do not
> > separate the APIs from implementation. This does not allow using
> > hardware queue implementations in pipeline model.
> > This change adds queue APIs and driver framework so that HW queues
> > can be used for core to core communication in pipeline model.
> > When different implementations (ex: HW queues and rte_ring) are used
>
> Just to understand, Do you have any HW in mind where it can do generic multi producer/multi consumer queue operations for core to core in HW as offload.
>
>> It is my understanding that NXP SoCs provide this capability (Hemant, please correct me if I am wrong).
>> It is not needed that the offload is a queue. It can be some other mechanism (for ex: enqueue/dequeue via the scheduler) as long as it performs better than the rte_ring implementation.
eventdev already abstracts CPU to CPU communication for HW offloads.
If NXP's HW comes under scheduler offload then it is already abstracted over eventdev.
I will let Hemant answer the specifics of NXP implementation.
Currently, the pipeline model does not use the event dev abstraction for CPU to CPU communication. One way is to use the event dev abstraction in the pipeline model.
>
> > for the same object in different platforms, it is important to make
> > sure that the application is portable. Hence features of different
> > implementations must be elevated to the API level, so that the
> > application writers can make the right choice.
> > Currently, basic APIs are created, will add more required APIs as
> > this progresses.
> >
> > Honnappa Nagarahalli (1):
> > queue: introduce queue APIs and driver framework
> >
> > lib/librte_queue/rte_queue.c | 122 ++++++++++++++++++++++
> > lib/librte_queue/rte_queue.h | 200 ++++++++++++++++++++++++++++++++++++
> > lib/librte_queue/rte_queue_driver.h | 157
> > ++++++++++++++++++++++++++++
> > 3 files changed, 479 insertions(+)
> > create mode 100644 lib/librte_queue/rte_queue.c create mode 100644
> > lib/librte_queue/rte_queue.h create mode 100644
> > lib/librte_queue/rte_queue_driver.h
> >
> > --
> > 2.7.4
> >
prev parent reply other threads:[~2018-07-16 2:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-27 16:06 Honnappa Nagarahalli
2018-06-27 16:06 ` Honnappa Nagarahalli
2018-06-27 16:19 ` Jerin Jacob
2018-07-11 2:02 ` Honnappa Nagarahalli
2018-07-11 6:51 ` Jerin Jacob
2018-07-16 2:51 ` Honnappa Nagarahalli [this message]
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=HE1PR0801MB19305DD6F2AA0467C1C1BE64985D0@HE1PR0801MB1930.eurprd08.prod.outlook.com \
--to=honnappa.nagarahalli@arm.com \
--cc=Gavin.Hu@arm.com \
--cc=dev@dpdk.org \
--cc=hemant.agrawal@nxp.com \
--cc=jerin.jacob@caviumnetworks.com \
--cc=nd@arm.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).