Hi Jerin,
> -----Original Message----- > From: Jerin Jacob <jerinjac...@gmail.com> > Sent: Thursday, September 2, 2021 12:20 PM > To: Kaladi, Ashok K <ashok.k.kal...@intel.com> > Cc: Harman Kalra <hka...@marvell.com>; Nithin Dabilpuram > <ndabilpu...@marvell.com>; Yigit, Ferruh <ferruh.yi...@intel.com>; > Burakov, Anatoly <anatoly.bura...@intel.com>; Richardson, Bruce > <bruce.richard...@intel.com>; Ananyev, Konstantin > <konstantin.anan...@intel.com>; Thomas Monjalon > <tho...@monjalon.net>; David Marchand <david.march...@redhat.com>; > jer...@marvell.com; Jayatheerthan, Jay <jay.jayatheert...@intel.com>; > Carrillo, Erik G <erik.g.carri...@intel.com>; Gujjar, Abhinandan S > <abhinandan.guj...@intel.com>; dev@dpdk.org; Ayyadurai, Balasankar > <balasankar.ayyadu...@intel.com>; Jakub Grajciar <jgraj...@cisco.com>; > mattias.ronnblom <mattias.ronnb...@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.kal...@intel.com> > wrote: > > > > Hi Jerin, > > Hi Ashok, > > > > > > > -----Original Message----- > > From: Jerin Jacob <jerinjac...@gmail.com> > > Sent: Wednesday, September 1, 2021 1:20 PM > > To: Kaladi, Ashok K <ashok.k.kal...@intel.com>; Harman Kalra > > <hka...@marvell.com>; Nithin Dabilpuram <ndabilpu...@marvell.com>; > > Yigit, Ferruh <ferruh.yi...@intel.com>; Burakov, Anatoly > > <anatoly.bura...@intel.com>; Richardson, Bruce > > <bruce.richard...@intel.com>; Ananyev, Konstantin > > <konstantin.anan...@intel.com>; Thomas Monjalon > <tho...@monjalon.net>; > > David Marchand <david.march...@redhat.com> > > Cc: jer...@marvell.com; Jayatheerthan, Jay > > <jay.jayatheert...@intel.com>; Carrillo, Erik G > > <erik.g.carri...@intel.com>; Gujjar, Abhinandan S > > <abhinandan.guj...@intel.com>; dev@dpdk.org; Ayyadurai, Balasankar > > <balasankar.ayyadu...@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 <jerinjac...@gmail.com> > wrote: > > > > > > On Wed, Sep 1, 2021 at 11:12 AM Kaladi, Ashok K > > > <ashok.k.kal...@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 ( jgraj...@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. > > > >
