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