From: "Gavin Hu (Arm Technology China)" <Gavin.Hu@arm.com>
To: "pbhagavatula@marvell.com" <pbhagavatula@marvell.com>,
"jerinj@marvell.com" <jerinj@marvell.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, nd <nd@arm.com>
Subject: Re: [dpdk-dev] [PATCH] event/octeontx2: use wfe while waiting for head
Date: Thu, 24 Oct 2019 15:53:21 +0000 [thread overview]
Message-ID: <AM0PR08MB53632D210D4DBC006C2987118F6A0@AM0PR08MB5363.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <20191023161244.3284-1-pbhagavatula@marvell.com>
Hi Pavan,
> -----Original Message-----
> From: pbhagavatula@marvell.com <pbhagavatula@marvell.com>
> Sent: Thursday, October 24, 2019 12:13 AM
> To: Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>;
> jerinj@marvell.com; Pavan Nikhilesh <pbhagavatula@marvell.com>
> Cc: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH] event/octeontx2: use wfe while waiting for
> head
>
> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>
> Use wfe to save power while waiting for tag to become head.
>
> SSO signals EVENTI to allow cores to exit from wfe when they
> are waiting for specific operations in which one of them is
> setting HEAD bit in GWS_TAG.
>
> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> ---
> drivers/event/octeontx2/otx2_worker.h | 30 ++++++++++++++++++++++++--
> -
> 1 file changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/event/octeontx2/otx2_worker.h
> b/drivers/event/octeontx2/otx2_worker.h
> index 4e971f27c..7a55caca5 100644
> --- a/drivers/event/octeontx2/otx2_worker.h
> +++ b/drivers/event/octeontx2/otx2_worker.h
> @@ -226,10 +226,34 @@ otx2_ssogws_swtag_wait(struct otx2_ssogws *ws)
> }
>
> static __rte_always_inline void
> -otx2_ssogws_head_wait(struct otx2_ssogws *ws, const uint8_t wait_flag)
> +otx2_ssogws_head_wait(struct otx2_ssogws *ws)
> {
> - while (wait_flag && !(otx2_read64(ws->tag_op) & BIT_ULL(35)))
> +#ifdef RTE_ARCH_ARM64
> + uint64_t tag;
> +
> + asm volatile (
> + " ldr %[tag], [%[tag_op]] \n"
"ldxr" should be used, exclusive-load is required to "monitor" the location, then a write to the location will cause clear of the exclusive monitor, thus a wake up event is generated implicitly.
You can find more explanation is here:
http://inbox.dpdk.org/dev/AM0PR08MB5363F9D1BA158B66B803EA068F6B0@AM0PR08MB5363.eurprd08.prod.outlook.com/
/Gavin
> + " tbnz %[tag], 35, done%= \n"
> + " sevl \n"
> + "rty%=: wfe \n"
> + " ldr %[tag], [%[tag_op]] \n"
> + " tbz %[tag], 35, rty%= \n"
> + "done%=: \n"
> + : [tag] "=&r" (tag)
> + : [tag_op] "r" (ws->tag_op)
> + );
> +#else
> + /* Wait for the HEAD to be set */
> + while (!(otx2_read64(ws->tag_op) & BIT_ULL(35)))
> ;
> +#endif
> +}
> +
> +static __rte_always_inline void
> +otx2_ssogws_order(struct otx2_ssogws *ws, const uint8_t wait_flag)
> +{
> + if (wait_flag)
> + otx2_ssogws_head_wait(ws);
>
> rte_cio_wmb();
What ordering does this barrier try to keep? If there is a write then wait for kind of response, should this barrier move before otx2_ssogws_head_wait?
/Gavin
> }
> @@ -258,7 +282,7 @@ otx2_ssogws_event_tx(struct otx2_ssogws *ws,
> struct rte_event ev[],
>
> /* Perform header writes before barrier for TSO */
> otx2_nix_xmit_prepare_tso(m, flags);
> - otx2_ssogws_head_wait(ws, !ev->sched_type);
> + otx2_ssogws_order(ws, !ev->sched_type);
> otx2_ssogws_prepare_pkt(txq, m, cmd, flags);
>
> if (flags & NIX_TX_MULTI_SEG_F) {
> --
> 2.17.1
next prev parent reply other threads:[~2019-10-24 15:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-23 16:12 pbhagavatula
2019-10-24 15:53 ` Gavin Hu (Arm Technology China) [this message]
2019-10-25 4:26 ` Pavan Nikhilesh Bhagavatula
2019-10-25 16:34 ` Gavin Hu (Arm Technology China)
2019-10-25 17:06 ` Pavan Nikhilesh Bhagavatula
2019-10-27 9:12 ` Gavin Hu (Arm Technology China)
2019-10-30 13:33 ` Jerin Jacob
2019-12-18 17:42 ` Honnappa Nagarahalli
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=AM0PR08MB53632D210D4DBC006C2987118F6A0@AM0PR08MB5363.eurprd08.prod.outlook.com \
--to=gavin.hu@arm.com \
--cc=dev@dpdk.org \
--cc=jerinj@marvell.com \
--cc=nd@arm.com \
--cc=pbhagavatula@marvell.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).