[dpdk-dev] [PATCH v4 2/6] eventdev: define southbound driver interface

Nipun Gupta nipun.gupta at nxp.com
Thu Feb 2 13:53:17 CET 2017



> -----Original Message-----
> From: Bruce Richardson [mailto:bruce.richardson at intel.com]
> Sent: Thursday, February 02, 2017 17:04
> To: Nipun Gupta <nipun.gupta at nxp.com>
> Cc: Jerin Jacob <jerin.jacob at caviumnetworks.com>; dev at dpdk.org;
> thomas.monjalon at 6wind.com; Hemant Agrawal <hemant.agrawal at nxp.com>;
> gage.eads at intel.com; harry.van.haaren at 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-bounces at dpdk.org] On Behalf Of Jerin Jacob
> > > Sent: Wednesday, December 21, 2016 14:55
> > > To: dev at dpdk.org
> > > Cc: thomas.monjalon at 6wind.com; bruce.richardson at intel.com; Hemant
> > > Agrawal <hemant.agrawal at nxp.com>; gage.eads at intel.com;
> > > harry.van.haaren at intel.com; Jerin Jacob
> > > <jerin.jacob at caviumnetworks.com>
> > > Subject: [dpdk-dev] [PATCH v4 2/6] eventdev: define southbound
> > > driver interface
> > >
> > > Signed-off-by: Jerin Jacob <jerin.jacob at caviumnetworks.com>
> > > Acked-by: Bruce Richardson <bruce.richardson at 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

> 
> /Bruce


More information about the dev mailing list