From: "Van Haaren, Harry" <harry.van.haaren@intel.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>,
"Elo, Matias (Nokia - FI/Espoo)" <matias.elo@nokia.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"mattias.ronnblom@ericsson.com" <mattias.ronnblom@ericsson.com>
Subject: Re: [dpdk-dev] eventdev: rte_event_dev_start() all queues are linked requirement
Date: Mon, 30 Jul 2018 09:15:13 +0000 [thread overview]
Message-ID: <E923DB57A917B54B9182A2E928D00FA65E2957B2@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <20180730080507.GA15830@jerin>
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Monday, July 30, 2018 9:05 AM
> To: Elo, Matias (Nokia - FI/Espoo) <matias.elo@nokia.com>
> Cc: dev@dpdk.org; Van Haaren, Harry <harry.van.haaren@intel.com>;
> mattias.ronnblom@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@nokia.com>
> > To: "dev@dpdk.org" <dev@dpdk.org>
> > CC: "jerin.jacob@caviumnetworks.com" <jerin.jacob@caviumnetworks.com>, "Van
> > Haaren, Harry" <harry.van.haaren@intel.com>
> > Subject: eventdev: rte_event_dev_start() all queues are linked requirement
> > x-mailer: Apple Mail (2.3445.9.1)
> >
>
> + mattias.ronnblom@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
prev parent reply other threads:[~2018-07-30 9:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-30 7:38 Elo, Matias (Nokia - FI/Espoo)
2018-07-30 8:05 ` Jerin Jacob
2018-07-30 9:15 ` Van Haaren, Harry [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E923DB57A917B54B9182A2E928D00FA65E2957B2@IRSMSX102.ger.corp.intel.com \
--to=harry.van.haaren@intel.com \
--cc=dev@dpdk.org \
--cc=jerin.jacob@caviumnetworks.com \
--cc=matias.elo@nokia.com \
--cc=mattias.ronnblom@ericsson.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).