DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob <jerinjacobk@gmail.com>
To: "Kaladi, Ashok K" <ashok.k.kaladi@intel.com>,
	Harman Kalra <hkalra@marvell.com>,
	 Nithin Dabilpuram <ndabilpuram@marvell.com>,
	Ferruh Yigit <ferruh.yigit@intel.com>,
	 Anatoly Burakov <anatoly.burakov@intel.com>,
	 "Richardson, Bruce" <bruce.richardson@intel.com>,
	 "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	 David Marchand <david.marchand@redhat.com>
Cc: "jerinj@marvell.com" <jerinj@marvell.com>,
	"Jayatheerthan, Jay" <jay.jayatheerthan@intel.com>,
	 "Carrillo, Erik G" <erik.g.carrillo@intel.com>,
	 "Gujjar, Abhinandan S" <abhinandan.gujjar@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	 "Ayyadurai, Balasankar" <balasankar.ayyadurai@intel.com>
Subject: Re: [dpdk-dev] [RFC] Control packet event adapter and FIFO library
Date: Wed, 1 Sep 2021 11:55:30 +0530	[thread overview]
Message-ID: <CALBAE1MRgi2-Yo51oSzojUNCuE0LpMSRGV8b_9b19K=26kdh1Q@mail.gmail.com> (raw)
In-Reply-To: <DM6PR11MB31133A5ADA68EB702EFC6817D0CD9@DM6PR11MB3113.namprd11.prod.outlook.com>

On Wed, Sep 1, 2021 at 11:12 AM Kaladi, Ashok K
<ashok.k.kaladi@intel.com> wrote:
>
> Dear dpdk-dev team,
>
> We would like to propose the following RFC for your review.
>
> A user space application may need access to the packets handled by eventdev
> based DPDK application. This application doesn't use mbuf or eventdev based
> DPDK APIs. Presently this is not possible without passing packets through
> DPDK KNI.


I think it is an innovative idea it is useful for multiple use cases
not just for eventdev.

Some feedback on thoughts

1) The FIFO library should be generic it should not be specific to eventdev
2) I think,  This FIFO library should be generic and  KNI also be a
consumer of this library
3) I think, FIFO should not be a device instead it should be an
abstact object like rte_mempool *
4) We need to consider User space app can be another DPDK primary
process or some non DPDK app
4) I think, we can remove the Linux shared memory dependency instead
of introduce some
scheme of "exporting" memzone from DPDK application to another user
space app or another DPDK primary process.
I see the following reasons:
- It is backed by hugepage so better performance
- Is kernel do any memcpy when using Linux shm calls in kernel space?

Thoughts?

May be you can share set of API prototypes without any implementation
for the next level discussion if
others are OK this kind of library.

>
> This RFC introduces control packet event adapter (CP adapter) and FIFO library
> which can be used by user space applications to access the packets
> handled by eventdev based DPDK application.  Linux shared memory is used to
> keep mempool (mbufs), packets and FIFOs. This allows copy-free access of
> packets to both the applications. The Rx and Tx FIFOs are used to exchange
> packets between the applications.
>
>                                     '------------------'
>                                     |     mempool      |
> '-------------'    '-----------'    |..................|    '----------'    '-----------'
> |             |    |           |    |  <--- Tx FIFOs   |    |          |    |           |
> | User space  |    |           |    |  <--- Alloc FIFO |    | Control  |    |   DPDK    |
> |    App      <---->  FIFO Lib <---->  ---> Rx FIFOs   <----> Packet   <----> Eventdev  |
> |             |    |           |    |  ---> Free FIFO  |    | Adapter  |    |   App     |
> |             |    |           |    |                  |    |          |    |           |
> '-------------'    '-----------'    |                  |    '----------'    '-----------'
>                                     '------------------'
>
> CP adapter does the mbuf allocation and free for user space application. Mbufs
> allocated for user space application are put into alloc queue by CP adapter.
> The used mbufs are put into free queue by user space application.
> The FIFO lib translates packets between rte_mbuf format and a simplified
> format which will be used by the user application. FIFO lib doesn't use any other
> DPDK features than rte_mbuf structure. The simplified packet format contains only
> essential parameters like address of the payload, packet length, etc.
>
> - user space app send path:  When user space application wants to send
>   a packet, it takes an mbufs from Alloc FIFO, writes packet to it and puts it
>   into Rx queue. CP adapter which polls this queue gets the packet and enqueues
>   to eventdev. Then the mbuf is freed by CP adapter.
>
> - use space app receive path: CP adapter puts the packets to Tx FIFO,
>   user space application polls the FIFO and gets the packet. After consuming
>   the packet it puts the mbuf to be freed to free FIFO. CP  adapter regularly
>   reads the free FIFO and frees the mbufs in it.
>
> The CP adapter can service multiple devices and queues. Each queue is
> configured with a servicing weight to control the relative frequency with which
> the adapter polls the queue, and the event fields to use when constructing
> packet events.
>
> API Summary
>
> FIFO APIs:
> -  FIFO device open/close.
> -  API to allocate PDU buffer from alloc queue.
> -  API to send a burst of packets to an Rx FIFO identified by FIFO id and device id.
> -  API to receive a burst of packets from Tx FIFO identified by FIFO id and device id.
> -  API to put the used buffer to Free queue. Use application will call this after
>    using the payload.
>
> Control Packet Adapter APIs:
> -  Initialization API.
> -  Device addition and removal APIs
> -  Device configuration APIs.
> -  FIFO add and remove APIs.
> -  Event enqueue and dequeue APIs.
>
>
> We look forward for your feedback on this proposal. Once we have initial feedback,
> patches will be submitted for review.
>
>
> Thanks & Regards
> Ashok Kaladi
>

  reply	other threads:[~2021-09-01  6:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-01  5:41 Kaladi, Ashok K
2021-09-01  6:25 ` Jerin Jacob [this message]
2021-09-01  7:49   ` Jerin Jacob
2021-09-02  4:32     ` Kaladi, Ashok K
2021-09-02  6:50       ` Jerin Jacob
2021-09-14 10:41         ` Kaladi, Ashok K
2021-09-01 19:45 ` Mattias Rönnblom

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='CALBAE1MRgi2-Yo51oSzojUNCuE0LpMSRGV8b_9b19K=26kdh1Q@mail.gmail.com' \
    --to=jerinjacobk@gmail.com \
    --cc=abhinandan.gujjar@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=ashok.k.kaladi@intel.com \
    --cc=balasankar.ayyadurai@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=erik.g.carrillo@intel.com \
    --cc=ferruh.yigit@intel.com \
    --cc=hkalra@marvell.com \
    --cc=jay.jayatheerthan@intel.com \
    --cc=jerinj@marvell.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=ndabilpuram@marvell.com \
    --cc=thomas@monjalon.net \
    /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).