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