From: "Liang, Cunming" <cunming.liang@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: Yong Wang <yongwang@vmware.com>, "dev@dpdk.org" <dev@dpdk.org>,
"david.marchand@6wind.com" <david.marchand@6wind.com>
Subject: Re: [dpdk-dev] [PATCH] eal: fix rte_intr_dp_is_en() check
Date: Wed, 20 Jul 2016 08:56:36 +0000 [thread overview]
Message-ID: <D0158A423229094DA7ABF71CF2FA0DA31554AED6@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <2847845.SJj9hZrsaB@xps13>
Hi Thomas,
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Wednesday, July 20, 2016 4:42 PM
> To: Liang, Cunming <cunming.liang@intel.com>
> Cc: Yong Wang <yongwang@vmware.com>; dev@dpdk.org;
> david.marchand@6wind.com
> Subject: Re: [dpdk-dev] [PATCH] eal: fix rte_intr_dp_is_en() check
>
> 2016-07-20 07:03, Liang, Cunming:
> > Probably a clean way is not to handle device external interrupt event in EAL
> > interrupt thread (intr mb may have some problem). The EAL interrupt thread
> is
> > only used to postpone the delay execution or other background interrupt
> > (e.g. alarm). Then misc/non-misc can be combined, while requiring APP to
> > detect the interrupt causes.
>
> I am not sure it was a good idea to have a thread for the link interrupt.
> It may be simpler and cleaner to let the application do the pthread_create.
The EAL intr thread is reserved for all interrupt before, is not design for link interrupt
on the first day. Personally I vote to remove link interrupt from interrupt thread.
-Cunming
prev parent reply other threads:[~2016-07-20 8:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-15 0:36 Yong Wang
2016-07-18 6:19 ` Liang, Cunming
2016-07-18 9:21 ` Thomas Monjalon
2016-07-19 21:58 ` Yong Wang
2016-07-20 7:03 ` Liang, Cunming
2016-07-20 8:41 ` Thomas Monjalon
2016-07-20 8:56 ` Liang, Cunming [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=D0158A423229094DA7ABF71CF2FA0DA31554AED6@shsmsx102.ccr.corp.intel.com \
--to=cunming.liang@intel.com \
--cc=david.marchand@6wind.com \
--cc=dev@dpdk.org \
--cc=thomas.monjalon@6wind.com \
--cc=yongwang@vmware.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).