> From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] > Sent: Monday, July 30, 2018 9:05 AM > To: Elo, Matias (Nokia - FI/Espoo) <matias....@nokia.com> > Cc: dev@dpdk.org; Van Haaren, Harry <harry.van.haa...@intel.com>; > mattias.ronnb...@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....@nokia.com> > > To: "dev@dpdk.org" <dev@dpdk.org> > > CC: "jerin.ja...@caviumnetworks.com" <jerin.ja...@caviumnetworks.com>, "Van > > Haaren, Harry" <harry.van.haa...@intel.com> > > Subject: eventdev: rte_event_dev_start() all queues are linked requirement > > x-mailer: Apple Mail (2.3445.9.1) > > > > + mattias.ronnb...@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
