[dpdk-dev] eventdev: rte_event_dev_start() all queues are linked requirement

[Van Haaren, Harry]

> From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
> Sent: Monday, July 30, 2018 9:05 AM
> To: Elo, Matias (Nokia - FI/Espoo) <matias.elo at nokia.com>
> Cc: dev at dpdk.org; Van Haaren, Harry <harry.van.haaren at intel.com>;
> mattias.ronnblom at ericsson.com
> Subject: Re: eventdev: rte_event_dev_start() all queues are linked requirement
> 
> -----Original Message-----
> > Date: Mon, 30 Jul 2018 07:38:27 +0000
> > From: "Elo, Matias (Nokia - FI/Espoo)" <matias.elo at nokia.com>
> > To: "dev at dpdk.org" <dev at dpdk.org>
> > CC: "jerin.jacob at caviumnetworks.com" <jerin.jacob at caviumnetworks.com>, "Van
> >  Haaren, Harry" <harry.van.haaren at intel.com>
> > Subject: eventdev: rte_event_dev_start() all queues are linked requirement
> > x-mailer: Apple Mail (2.3445.9.1)
> >
> 
> + mattias.ronnblom at ericsson.com as his SW driver is scheduled for next
> release.
> 
> >
> > Hi,
> >
> > rte_event_dev_start() requires that all queues have to be linked, which
> makes
> > writing applications which link/unlink queues at runtime cumbersome.
> > E.g. the application has to dummy link all queues before
> rte_event_dev_start()
> > and then unlink them after the function call. This alone wouldn't be a big
> issue
> > but rte_event_dev_start() may also be called inside
> > rte_event_eth_rx_adapter_create() implementation causing additional
> complexity.
> >
> > To me this check seems more like eventdev implementation specific
> limitation,
> > which should be solved by the particular implementation and not enforced by
> the
> > API to all applications. From an application point of view enqueueing events
> to
> > an unlinked queue and expecting something meaningful to happen is an error
> > anyway. So, would it be conceivable to remove this particular requirement?
> 
> For HW drivers, It is OK remove the particular requirement. But, If
> there is an issue(performance/functionality) for enabling such feature
> in SW driver. I would like keep that constraint to keep eventdev as
> abstraction for both SW and HW driver. Harry and/or Mattias.ronnblom can
> comment from SW driver perspective.


I don't have any objection to removing this restriction.

Initially it was added to the event/sw driver as it avoids a potential
deadlock situation if no ports are mapped to a queue, and the application
enqueues events to the queue. As a result the queue will backpressure until
the whole thing stops.

I'm aware that this is incorrect usage - if events are enqueued to a queue
the application is responsible for configuring the ports to pull those events
out again... we thought this would help the user - but it looks to do the opposite.

Currently this is NOT enforced by the lib/eventdev layer (as far as I can see)?
I don't think the header file suggests such behavior either...

In event/sw we have a check that fails - but we can relax that check.
I'll wait a day or two for some more input, and send a patch for event/sw then.


Thanks @Matias Elo for bringing attention to this! -Harry