From: Pavan Nikhilesh Bhagavatula <pbhagavatula@caviumnetworks.com>
To: "Van Haaren, Harry" <harry.van.haaren@intel.com>
Cc: dev@dpdk.org
Subject: Re: [PATCH 1/3] evendev: fix inconsistency in event queue config
Date: Fri, 20 Oct 2017 16:00:33 +0530 [thread overview]
Message-ID: <20171020103032.GA7404@PBHAGAVATULA-LT> (raw)
In-Reply-To: <E923DB57A917B54B9182A2E928D00FA650FC91E3@IRSMSX102.ger.corp.intel.com>
On Fri, Oct 20, 2017 at 09:54:36AM +0000, Van Haaren, Harry wrote:
> > From: Pavan Nikhilesh [mailto:pbhagavatula@caviumnetworks.com]
> > Sent: Thursday, October 12, 2017 2:16 PM
> > To: jerin.jacob@caviumnetworks.com; hemant.agrawal@nxp.com; Van Haaren,
> > Harry <harry.van.haaren@intel.com>
> > Cc: dev@dpdk.org; Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
> > Subject: [dpdk-dev] [PATCH 1/3] evendev: fix inconsistency in event queue
> > config
> >
> > With the current scheme of event queue configuration the cfg schedule
> > type macros (RTE_EVENT_QUEUE_CFG_*_ONLY) are inconsistent with the
> > event schedule type (RTE_SCHED_TYPE_*) this requires unnecessary
> > conversion between the fastpath and slowpath API's while scheduling
> > events or configuring event queues.
> >
> > This patch aims to fix such inconsistency by using event schedule
> > types (RTE_SCHED_TYPE_*) for event queue configuration.
>
> True - worth cleaning up.
>
>
> > This patch also fixes example/eventdev_pipeline_sw_pmd as it doesn't
> > convert RTE_EVENT_QUEUE_CFG_*_ONLY to RTE_SCHED_TYPE_* which leads to
> > improper events being enqueued to the eventdev.
> >
> > Fixes: adb5d5486c39 ("examples/eventdev_pipeline_sw_pmd: add sample app")
> >
> > Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
> >
> >
> > app/test-eventdev/evt_common.h | 21 -------------
> > app/test-eventdev/test_order_queue.c | 4 +--
> > app/test-eventdev/test_perf_queue.c | 4 +--
> > drivers/event/dpaa2/dpaa2_eventdev.c | 4 +--
> > drivers/event/sw/sw_evdev.c | 28 +++++------------
> > examples/eventdev_pipeline_sw_pmd/main.c | 18 +++++------
> > lib/librte_eventdev/rte_eventdev.c | 20 +++++-------
> > lib/librte_eventdev/rte_eventdev.h | 54 ++++++++++-------------------
> > ---
> > test/test/test_eventdev.c | 12 +++----
> > test/test/test_eventdev_sw.c | 16 +++++-----
> > 10 files changed, 60 insertions(+), 121 deletions(-)
> >
> > diff --git a/app/test-eventdev/evt_common.h b/app/test-eventdev/evt_common.h
> > index 4102076..ee896a2 100644
> > --- a/app/test-eventdev/evt_common.h
> > +++ b/app/test-eventdev/evt_common.h
> > @@ -92,25 +92,4 @@ evt_has_all_types_queue(uint8_t dev_id)
> > true : false;
> > }
> >
> > -static inline uint32_t
> > -evt_sched_type2queue_cfg(uint8_t sched_type)
> > -{
> > - uint32_t ret;
> > -
> > - switch (sched_type) {
> > - case RTE_SCHED_TYPE_ATOMIC:
> > - ret = RTE_EVENT_QUEUE_CFG_ATOMIC_ONLY;
> > - break;
> > - case RTE_SCHED_TYPE_ORDERED:
> > - ret = RTE_EVENT_QUEUE_CFG_ORDERED_ONLY;
> > - break;
> > - case RTE_SCHED_TYPE_PARALLEL:
> > - ret = RTE_EVENT_QUEUE_CFG_PARALLEL_ONLY;
> > - break;
> > - default:
> > - rte_panic("Invalid sched_type %d\n", sched_type);
> > - }
> > - return ret;
> > -}
>
>
> We should note here, that SCHED_TYPE are integer values:
> #define RTE_SCHED_TYPE_ORDERED 0
> #define RTE_SCHED_TYPE_ATOMIC 1
> #define RTE_SCHED_TYPE_PARALLEL 2
>
> While the EVENT_QUEUE_CFG_ types were bitmasks (before being removed in this patch)
> #define RTE_EVENT_QUEUE_CFG_ATOMIC_ONLY (1ULL << 0)
> #define RTE_EVENT_QUEUE_CFG_ORDERED_ONLY (2ULL << 0)
> #define RTE_EVENT_QUEUE_CFG_PARALLEL_ONLY (3ULL << 0)
> #define RTE_EVENT_QUEUE_CFG_SINGLE_LINK (1ULL << 2)
>
>
> I'm not against this change - but we must be careful that if there was any bit-masking being used previously,
> that that will subtly have broken if we change to sched types. I'm reviewing with that in mind..
>
> The RTE_EVENT_QUEUE_CFG_ALL_TYPES config flag now means that all SCHED_TYPEs
> are valid. Previously this was contained in the bitmask.. this may lead to issues.
>
> See patch 2/3, where *only* the schedule_type is read, and returned. What if it the "ALL_TYPES" flag is
> set on the queue? It will be reported wrongly. Currently there is no integer value for "ALL_TYPES",
> so we cannot represent "ALL TYPES" in the return value from get_attr().
>
> Am I explaining my reasoning clearly enough?
>
Hey Harry,
I do understand what you mean, my initial thought was to include "ALL_TYPES" as
a schedule_type in queue config but this would just complicate things.
As these values are only used in config phase we could have a check to see if
event_queue_cfg is not "ALL_TYPES" and only then return the value of sched_type
else return a error value in case of get_attr().
I think most of the places this specific check is handled, one such missed
place would be get_attr(). If we could come to a conclusion to fix it in a
correct way I will send out a v2.
Thanks,
Pavan.
>
> The patch correctly leaves QUEUE_CFG_SINGLE_LINK as a bitmask, so that bit is ok.
>
>
>
> > #endif /* _EVT_COMMON_*/
> > diff --git a/app/test-eventdev/test_order_queue.c b/app/test-
> > eventdev/test_order_queue.c
> > index beadd9c..1fa4082 100644
>
>
> <snip> Remaining diff was updating the QUEUE_CFG to SCHED_TYPE </snip>
next prev parent reply other threads:[~2017-10-20 10:30 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-12 13:15 [PATCH 1/3] evendev: fix inconsistency in event queue config Pavan Nikhilesh
2017-10-12 13:15 ` [PATCH 2/3] eventdev: extend queue attribute get function Pavan Nikhilesh
2017-10-12 13:15 ` [PATCH 3/3] doc: update eventdev programmers guide Pavan Nikhilesh
2017-10-20 9:54 ` [PATCH 1/3] evendev: fix inconsistency in event queue config Van Haaren, Harry
2017-10-20 10:30 ` Pavan Nikhilesh Bhagavatula [this message]
2017-10-20 16:38 ` Van Haaren, Harry
2017-10-20 19:09 ` Pavan Nikhilesh Bhagavatula
2017-10-21 17:27 ` Jerin Jacob
2017-10-23 8:04 ` Van Haaren, Harry
2017-10-23 8:41 ` Pavan Nikhilesh Bhagavatula
2017-10-23 14:45 ` Van Haaren, Harry
2017-10-23 14:54 ` Pavan Nikhilesh Bhagavatula
2017-10-21 15:05 ` Jerin Jacob
2017-10-23 16:29 ` [PATCH v2 " Pavan Nikhilesh
2017-10-23 16:29 ` [PATCH v2 2/3] eventdev: extend queue attribute get function Pavan Nikhilesh
2017-10-23 16:29 ` [PATCH v2 3/3] doc: update eventdev programmers guide Pavan Nikhilesh
2017-10-23 17:40 ` [PATCH v3 1/3] evendev: fix inconsistency in event queue config Pavan Nikhilesh
2017-10-23 17:40 ` [PATCH v3 2/3] eventdev: extend queue attribute get function Pavan Nikhilesh
2017-10-25 13:43 ` Van Haaren, Harry
2017-10-25 13:58 ` Pavan Nikhilesh Bhagavatula
2017-10-23 17:40 ` [PATCH v3 3/3] doc: update eventdev programmers guide Pavan Nikhilesh
2017-10-25 13:43 ` Van Haaren, Harry
2017-10-25 13:42 ` [PATCH v3 1/3] evendev: fix inconsistency in event queue config Van Haaren, Harry
2017-10-25 14:21 ` [PATCH v4 " Pavan Nikhilesh
2017-10-25 14:21 ` [PATCH v4 2/3] eventdev: extend queue attribute get function Pavan Nikhilesh
2017-10-25 14:21 ` [PATCH v4 3/3] doc: update eventdev programmers guide Pavan Nikhilesh
2017-10-26 22:26 ` [PATCH v4 1/3] evendev: fix inconsistency in event queue config Thomas Monjalon
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=20171020103032.GA7404@PBHAGAVATULA-LT \
--to=pbhagavatula@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.