DPDK patches and discussions
 help / color / mirror / Atom feed
From: Harman Kalra <hkalra@marvell.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Sunil Kumar Kori <skori@marvell.com>,
	Bruce Richardson <bruce.richardson@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/4] eal: add API to check if its interrupt context
Date: Thu, 28 Nov 2019 08:10:23 +0000	[thread overview]
Message-ID: <20191128081006.GA50093@outlook.office365.com> (raw)
In-Reply-To: <20191127160319.27915b22@hermes.lan>

On Wed, Nov 27, 2019 at 04:03:19PM -0800, Stephen Hemminger wrote:
> External Email
> 
> ----------------------------------------------------------------------
> On Wed, 27 Nov 2019 15:52:19 +0530
> Sunil Kumar Kori <skori@marvell.com> wrote:
> 
> >  
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice
> > + *
> > + * Check if currently executing in interrupt context
> > + *
> > + * @return
> > + *  - positive in case of interrupt context
> > + *  - zero in case of process context
> > + *  - negative if unsuccessful
> > + */
> > +__rte_experimental
> > +int
> > +rte_thread_is_intr(void);
> 
> If you only need this in drivers, it should be internal not exposed
> as part of API

Sorry, but can you please help me understand the query. Do you mean:
* Since "rte_thread_is_intr"  would be used only used by
libraries/drivers and not by any external application, rather having
it in "rte_interrupt.h", we should have it in some internal header
file like "eal_private.h" ??

ANS - Yes we can do that but since all other related APIs like
"rte_intr_ack", "rte_intr_enable/disable" which are also used by
drivers/lib and not application, are prototyped in "rte_interupt.h".

OR do u mean
* Since only octeontx2 driver is using this, why it is exposed as an API
rather it should be defined as some driver internal function ??

ANS - "rte_thread_is_intr" is an counter part of "in_interrupt()" in
DPDK, which will return whether the current execution is in interrupt
context. This helps in dealing with nested interrupts case. We faced a
similar case while handling hotplug probing initiated via secondary
process.
We believe this API could be very useful for many drivers which might
end up in handling nested interrupts case.

Thanks
Harman

  reply	other threads:[~2019-11-28  8:10 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-25 11:35 [dpdk-dev] [PATCH 1/5] drivers/octeontx2: allow experimental symbols Sunil Kumar Kori
2019-11-25 11:35 ` [dpdk-dev] [PATCH v3 2/5] eal: add API to check if its interrupt context Sunil Kumar Kori
2019-11-25 11:35 ` [dpdk-dev] [PATCH 3/5] common/octeontx2: add interrupt offset to mbox structure Sunil Kumar Kori
2019-11-25 11:35 ` [dpdk-dev] [PATCH 4/5] common/octeontx2: add polling based response mbox message Sunil Kumar Kori
2019-11-25 11:35 ` [dpdk-dev] [PATCH 5/5] common/octeontx2: enhancing mbox APIs to get response Sunil Kumar Kori
2019-11-26  6:15 ` [dpdk-dev] [PATCH v2 1/5] drivers/octeontx2: allow experimental symbols Sunil Kumar Kori
2019-11-26 16:21   ` Thomas Monjalon
2019-11-27  8:34     ` [dpdk-dev] [EXT] " Sunil Kumar Kori
2019-11-27  9:42       ` Thomas Monjalon
2019-11-27 10:22   ` [dpdk-dev] [PATCH v2 1/4] eal: add API to check if its interrupt context Sunil Kumar Kori
2019-11-27 10:22     ` [dpdk-dev] [PATCH v2 2/4] common/octeontx2: add interrupt offset to mbox structure Sunil Kumar Kori
2019-11-27 10:22     ` [dpdk-dev] [PATCH v2 3/4] common/octeontx2: add polling based response mbox message Sunil Kumar Kori
2019-11-27 10:22     ` [dpdk-dev] [PATCH v2 4/4] drivers/octeontx2: enhancing mbox APIs to get response Sunil Kumar Kori
2019-11-28  0:03     ` [dpdk-dev] [PATCH v2 1/4] eal: add API to check if its interrupt context Stephen Hemminger
2019-11-28  8:10       ` Harman Kalra [this message]
2019-11-28 16:45         ` [dpdk-dev] [EXT] " Stephen Hemminger
2019-12-04 16:23           ` Harman Kalra
2019-12-16 10:39     ` [dpdk-dev] [PATCH v3 1/2] " Sunil Kumar Kori
2019-12-16 10:39       ` [dpdk-dev] [PATCH v3 2/2] common/octeontx2: add polling based response mbox message Sunil Kumar Kori
2019-12-17  8:02         ` Gavin Hu (Arm Technology China)
2019-12-17 11:14           ` Jerin Jacob
2019-12-18  2:45             ` Gavin Hu
2019-12-17 10:42         ` [dpdk-dev] [PATCH v4 1/2] eal: add API to check if its interrupt context Sunil Kumar Kori
2019-12-17 10:42           ` [dpdk-dev] [PATCH v4 2/2] common/octeontx2: add polling based response mbox message Sunil Kumar Kori
2019-12-17 16:53         ` [dpdk-dev] [PATCH v4 1/2] eal: add API to check if its interrupt context Sunil Kumar Kori
2019-12-17 16:53           ` [dpdk-dev] [PATCH v4 2/2] common/octeontx2: add polling based response mbox message Sunil Kumar Kori
2019-12-18  2:54             ` Gavin Hu
2019-12-18  7:07           ` [dpdk-dev] [PATCH v5 1/2] eal: add API to check if its interrupt context Sunil Kumar Kori
2019-12-18  7:07             ` [dpdk-dev] [PATCH v5 2/2] common/octeontx2: add polling based response mbox message Sunil Kumar Kori
2019-12-20  6:56               ` [dpdk-dev] [PATCH v6 1/2] eal: add API to check if its interrupt context Sunil Kumar Kori
2019-12-20  6:56                 ` [dpdk-dev] [PATCH v6 2/2] common/octeontx2: add polling based response mbox message Sunil Kumar Kori
2020-01-14  8:41                   ` Jerin Jacob
2020-01-14 10:17                     ` Thomas Monjalon
2020-01-14  9:04                   ` [dpdk-dev] [PATCH v7 1/2] eal: add API to check if its interrupt context Sunil Kumar Kori
2020-01-14  9:04                     ` [dpdk-dev] [PATCH v7 2/2] common/octeontx2: add polling based response mbox message Sunil Kumar Kori
2020-01-21  8:37                       ` Sunil Kumar Kori
2020-02-06 15:35                     ` [dpdk-dev] [PATCH v7 1/2] eal: add API to check if its interrupt context David Marchand
2020-01-14  8:37                 ` [dpdk-dev] [PATCH v6 " 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=20191128081006.GA50093@outlook.office365.com \
    --to=hkalra@marvell.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=skori@marvell.com \
    --cc=stephen@networkplumber.org \
    /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).