Hi Jerin,
> -----Original Message----- > From: Jerin Jacob <[email protected]> > Sent: Thursday, September 2, 2021 12:20 PM > To: Kaladi, Ashok K <[email protected]> > Cc: Harman Kalra <[email protected]>; Nithin Dabilpuram > <[email protected]>; Yigit, Ferruh <[email protected]>; > Burakov, Anatoly <[email protected]>; Richardson, Bruce > <[email protected]>; Ananyev, Konstantin > <[email protected]>; Thomas Monjalon > <[email protected]>; David Marchand <[email protected]>; > [email protected]; Jayatheerthan, Jay <[email protected]>; > Carrillo, Erik G <[email protected]>; Gujjar, Abhinandan S > <[email protected]>; [email protected]; Ayyadurai, Balasankar > <[email protected]>; Jakub Grajciar <[email protected]>; > mattias.ronnblom <[email protected]> > Subject: Re: [dpdk-dev] [RFC] Control packet event adapter and FIFO library > > On Thu, Sep 2, 2021 at 10:02 AM Kaladi, Ashok K <[email protected]> > wrote: > > > > Hi Jerin, > > Hi Ashok, > > > > > > > -----Original Message----- > > From: Jerin Jacob <[email protected]> > > Sent: Wednesday, September 1, 2021 1:20 PM > > To: Kaladi, Ashok K <[email protected]>; Harman Kalra > > <[email protected]>; Nithin Dabilpuram <[email protected]>; > > Yigit, Ferruh <[email protected]>; Burakov, Anatoly > > <[email protected]>; Richardson, Bruce > > <[email protected]>; Ananyev, Konstantin > > <[email protected]>; Thomas Monjalon > <[email protected]>; > > David Marchand <[email protected]> > > Cc: [email protected]; Jayatheerthan, Jay > > <[email protected]>; Carrillo, Erik G > > <[email protected]>; Gujjar, Abhinandan S > > <[email protected]>; [email protected]; Ayyadurai, Balasankar > > <[email protected]> > > Subject: Re: [dpdk-dev] [RFC] Control packet event adapter and FIFO > > library > > > > On Wed, Sep 1, 2021 at 11:55 AM Jerin Jacob <[email protected]> > wrote: > > > > > > On Wed, Sep 1, 2021 at 11:12 AM Kaladi, Ashok K > > > <[email protected]> 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 ( [email protected] ) > > 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. > > > >
