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

["Kaladi, Ashok K" <ashok.k.kaladi@intel.com>]

Hi Jerin,


> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Thursday, September 2, 2021 12:20 PM
> To: Kaladi, Ashok K <ashok.k.kaladi@intel.com>
> Cc: Harman Kalra <hkalra@marvell.com>; Nithin Dabilpuram
> <ndabilpuram@marvell.com>; Yigit, Ferruh <ferruh.yigit@intel.com>;
> Burakov, Anatoly <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>;
> 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; Ayyadurai, Balasankar
> <balasankar.ayyadurai@intel.com>; Jakub Grajciar <jgrajcia@cisco.com>;
> mattias.ronnblom <mattias.ronnblom@ericsson.com>
> Subject: Re: [dpdk-dev] [RFC] Control packet event adapter and FIFO library
> 
> On Thu, Sep 2, 2021 at 10:02 AM Kaladi, Ashok K <ashok.k.kaladi@intel.com>
> wrote:
> >
> > Hi Jerin,
> 
> Hi Ashok,
> 
> >
> >
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Wednesday, September 1, 2021 1:20 PM
> > To: Kaladi, Ashok K <ashok.k.kaladi@intel.com>; Harman Kalra
> > <hkalra@marvell.com>; Nithin Dabilpuram <ndabilpuram@marvell.com>;
> > Yigit, Ferruh <ferruh.yigit@intel.com>; Burakov, Anatoly
> > <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; Jayatheerthan, Jay
> > <jay.jayatheerthan@intel.com>; Carrillo, Erik G
> > <erik.g.carrillo@intel.com>; Gujjar, Abhinandan S
> > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Ayyadurai, Balasankar
> > <balasankar.ayyadurai@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@gmail.com>
> wrote:
> > >
> > > 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
> >
> > 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@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?
> 
[Ashok Kaladi] 

Thanks for pointing it out. 
Checked the memif implementation and see that it doesn't have any other notable downsides than Linux dependency.
So we are withdrawing this RFC.

Regards
Ashok

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