[dpdk-dev] [RFC] Control packet event adapter and FIFO library

[Jerin Jacob]

On Thu, Sep 2, 2021 at 10:02 AM Kaladi, Ashok K
<ashok.k.kaladi at intel.com> wrote:
>
> Hi Jerin,

Hi Ashok,

>
>
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk at gmail.com>
> Sent: Wednesday, September 1, 2021 1:20 PM
> To: Kaladi, Ashok K <ashok.k.kaladi at intel.com>; Harman Kalra <hkalra at marvell.com>; Nithin Dabilpuram <ndabilpuram at marvell.com>; Yigit, Ferruh <ferruh.yigit at intel.com>; Burakov, Anatoly <anatoly.burakov at intel.com>; Richardson, Bruce <bruce.richardson at intel.com>; Ananyev, Konstantin <konstantin.ananyev at intel.com>; Thomas Monjalon <thomas at monjalon.net>; David Marchand <david.marchand at redhat.com>
> Cc: jerinj at marvell.com; Jayatheerthan, Jay <jay.jayatheerthan at intel.com>; Carrillo, Erik G <erik.g.carrillo at intel.com>; Gujjar, Abhinandan S <abhinandan.gujjar at intel.com>; dev at dpdk.org; Ayyadurai, Balasankar <balasankar.ayyadurai at intel.com>
> Subject: Re: [dpdk-dev] [RFC] Control packet event adapter and FIFO library
>
> On Wed, Sep 1, 2021 at 11:55 AM Jerin Jacob <jerinjacobk at gmail.com> wrote:
> >
> > On Wed, Sep 1, 2021 at 11:12 AM Kaladi, Ashok K
> > <ashok.k.kaladi at 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
>
> Agreed, it's planned to be generic.
>
> > 2) I think,  This FIFO library should be generic and  KNI also be a
> > consumer of this library
>
> Agreed,  any adaptation needed in KNI can be taken up later.
>
> > 3) I think, FIFO should not be a device instead it should be an
> > abstact object like rte_mempool *
>
> FIFO is comparable to queue. We will have a data structure which contains address of Rx, Tx, Alloc & Free FIFOs, number of queues etc.
> This can be used to create a device. This method is similar to KNI -  struct kni_dev.
>
> > 4) We need to consider User space app can be another DPDK primary
> > process or some non DPDK app
>
> Agreed
>
> > 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?
>
> We are proposing to use POSIX complaint APIs shm_open(), mmap() APIs to create shared memory to avoid dependency on Linux.
> The shared memory is created in Hugepages and contains mempool and mbufs. This is done by control packet adapter.
> This avoids application to be aware of these DPDK constructs. It just needs to know about the simplified format defined by FIFO lib.
> Proposed use case is for user space application which doesn’t need memcpy as mempool is in shared memory.
> For Kernel application we may use similar approach as in KNI. This can be taken up later.

+ memif maintainer ( jgrajcia at cisco.com )

I just looked memif, based on a suggestion from @Mattias Rönnblom

Looks like memif is already solved this problem in a clean way and
DPDK has support for the same as ethdev driver.
I think, it has only a downside that it has Linux OS dependency due to
memfd_create(). Any other downside for memif?
I think, may be,  we need to weigh in pros and cons of memif vs new
proposing library. Could you check the same?

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