From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Harry van Haaren <harry.van.haaren@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] eventdev: remove default queue overriding
Date: Mon, 6 Mar 2017 19:15:20 +0530 [thread overview]
Message-ID: <20170306134519.GA7397@localhost.localdomain> (raw)
In-Reply-To: <1488372542-156763-1-git-send-email-harry.van.haaren@intel.com>
On Wed, Mar 01, 2017 at 12:49:02PM +0000, Harry van Haaren wrote:
> PMDs that only do a specific type of scheduling cannot provide
> CFG_ALL_TYPES, so the Eventdev infrastructure should not demand
> that every PMD supports CFG_ALL_TYPES.
Sure. Then I think then we can enumerate CFG_ALL_TYPES as capability.
Meaning, New flag in event_dev_cap to denote PMD can support all the sched type
per queue. My reasoning for the capability flag is because, The application flow
will be depended on the logic of creating the queue with different flags.
Thoughts ?
I thought, In SW implementation, We can create 3 virtual queues per
queue. Based on en-queue's shed_type, implementation can choose the
correct underneath virtual queue. I guess, it has performance issues,
if so, Maybe capability is the way forward.
Setting to CFG_ALL_TYPES will be useful for flow based event pipeling
as I mentioned earlier in other email.
> By not overriding the default configuration of the queue as
> suggested by the PMD, the eventdev_common unit tests can pass
> on all PMDs, regardless of thier capabilities.
Make sense. We can remove the default as CFG_ALL_TYPES.
>
> RTE_EVENT_QUEUE_CFG_DEFAULT is no longer used by the eventdev layer
> it can be removed now. Applications should use CFG_ALL_TYPES
> if they require enqueue of all types a queue.
>
> Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com>
> ---
> lib/librte_eventdev/rte_eventdev.c | 1 -
> lib/librte_eventdev/rte_eventdev.h | 6 ------
> 2 files changed, 7 deletions(-)
>
> diff --git a/lib/librte_eventdev/rte_eventdev.c b/lib/librte_eventdev/rte_eventdev.c
> index 68bfc3b..c32a776 100644
> --- a/lib/librte_eventdev/rte_eventdev.c
> +++ b/lib/librte_eventdev/rte_eventdev.c
> @@ -593,7 +593,6 @@ rte_event_queue_setup(uint8_t dev_id, uint8_t queue_id,
> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->queue_def_conf,
> -ENOTSUP);
> (*dev->dev_ops->queue_def_conf)(dev, queue_id, &def_conf);
> - def_conf.event_queue_cfg = RTE_EVENT_QUEUE_CFG_DEFAULT;
> queue_conf = &def_conf;
> }
>
> diff --git a/lib/librte_eventdev/rte_eventdev.h b/lib/librte_eventdev/rte_eventdev.h
> index 7073987..d836f61 100644
> --- a/lib/librte_eventdev/rte_eventdev.h
> +++ b/lib/librte_eventdev/rte_eventdev.h
> @@ -471,12 +471,6 @@ rte_event_dev_configure(uint8_t dev_id,
> /* Event queue specific APIs */
>
> /* Event queue configuration bitmap flags */
> -#define RTE_EVENT_QUEUE_CFG_DEFAULT (0)
> -/**< Default value of *event_queue_cfg* when rte_event_queue_setup() invoked
> - * with queue_conf == NULL
> - *
> - * @see rte_event_queue_setup()
> - */
> #define RTE_EVENT_QUEUE_CFG_TYPE_MASK (3ULL << 0)
> /**< Mask for event queue schedule type configuration request */
> #define RTE_EVENT_QUEUE_CFG_ALL_TYPES (0ULL << 0)
> --
> 2.7.4
>
next prev parent reply other threads:[~2017-03-06 13:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-01 12:49 Harry van Haaren
2017-03-06 13:45 ` Jerin Jacob [this message]
2017-03-08 12:11 ` Van Haaren, Harry
2017-03-10 15:19 ` [dpdk-dev] [PATCH v2] " Harry van Haaren
2017-03-21 8:21 ` Jerin Jacob
2017-03-23 10:17 ` Jerin Jacob
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=20170306134519.GA7397@localhost.localdomain \
--to=jerin.jacob@caviumnetworks.com \
--cc=dev@dpdk.org \
--cc=harry.van.haaren@intel.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).