On Thu, Feb 02, 2017 at 12:53:17PM +0000, Nipun Gupta wrote: > > > > -----Original Message----- > > From: Bruce Richardson [mailto:bruce.richard...@intel.com] > > Sent: Thursday, February 02, 2017 17:04 > > To: Nipun Gupta <nipun.gu...@nxp.com> > > Cc: Jerin Jacob <jerin.ja...@caviumnetworks.com>; dev@dpdk.org; > > thomas.monja...@6wind.com; Hemant Agrawal <hemant.agra...@nxp.com>; > > gage.e...@intel.com; harry.van.haa...@intel.com > > Subject: Re: [dpdk-dev] [PATCH v4 2/6] eventdev: define southbound driver > > interface > > > > On Thu, Feb 02, 2017 at 11:19:51AM +0000, Nipun Gupta wrote: > > > > > > > > > > -----Original Message----- > > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jerin Jacob > > > > Sent: Wednesday, December 21, 2016 14:55 > > > > To: dev@dpdk.org > > > > Cc: thomas.monja...@6wind.com; bruce.richard...@intel.com; Hemant > > > > Agrawal <hemant.agra...@nxp.com>; gage.e...@intel.com; > > > > harry.van.haa...@intel.com; Jerin Jacob > > > > <jerin.ja...@caviumnetworks.com> > > > > Subject: [dpdk-dev] [PATCH v4 2/6] eventdev: define southbound > > > > driver interface > > > > > > > > Signed-off-by: Jerin Jacob <jerin.ja...@caviumnetworks.com> > > > > Acked-by: Bruce Richardson <bruce.richard...@intel.com> > > > > --- > > > > lib/librte_eventdev/rte_eventdev.h | 38 +++++ > > > > lib/librte_eventdev/rte_eventdev_pmd.h | 294 > > > > +++++++++++++++++++++++++++++++++ > > > > 2 files changed, 332 insertions(+) > > > > create mode 100644 lib/librte_eventdev/rte_eventdev_pmd.h > > > > > > > > > > <snip> > > > > > > > +typedef int (*eventdev_port_link_t)(void *port, > > > > + const uint8_t queues[], const uint8_t priorities[], > > > > + uint16_t nb_links); > > > > > > I think having event device as input parameter to the port_link & > > > port_unlink will be required so that queue configuration can be fetched > > > from > > the event device. > > > > > Or each port structure in each driver can have a pointer back to its > > containing > > eventdev. That is what we have done in our SW eventdev driver. > > That's one solution, but I think having device in the API will be more > cleaner here, just like > it is provided in other configuration API's? > > Thanks, > Nipun > Sure. Will you do up a patch to make this change, since the code is already applied to next-event tree?
/Bruce
