From: "Zhang, Qi Z" <qi.z.zhang@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, "Wu, Jingjing" <jingjing.wu@intel.com>
Subject: Re: [dpdk-dev] [PATCH] eal: fix max number of interrupt request
Date: Mon, 13 Feb 2017 01:16:11 +0000 [thread overview]
Message-ID: <039ED4275CED7440929022BC67E706115305B067@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <3158466.ioj3dkTVO6@xps13>
Hi Thomas:
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Friday, February 10, 2017 6:19 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: dev@dpdk.org; Wu, Jingjing <jingjing.wu@intel.com>
> Subject: Re: [PATCH] eal: fix max number of interrupt request
>
> 2017-02-09 14:59, Qi Zhang:
> > The max number of interrupt request is possible be changed after
> > rte_intr_callback_register, so in get_max_intr, we need to check if
> > nessesary to update the max_intr.
>
> So you are using rte_intr_enable() to update the max_intr field in the case of
> VFIO_MSIX.
> What about MSI, INTX and UIO cases?
My thought is, even without my fix, VFIO_MSIX is already the only case that try to modify max_intr field
In get_max_intr, we have:
if (!src->intr_handle.max_intr)
src->intr_handle.max_intr = 1;
else if (src->intr_handle.max_intr > RTE_MAX_RXTX_INTR_VEC_ID)
src->intr_handle.max_intr
= RTE_MAX_RXTX_INTR_VEC_ID + 1;
So my patch just follow this and fix some problem.
Another option is I can use a local variable that assigned by max_intr with boundary check, so get_max_intr can be totally removed and max_intr in intr_source will not be modified.
To me both fix are not perfect, I think the problem is in rte_intr_callback_register we just save a copy of the pci_dev->intr_handle but not the address point, so we are missing some mechanism to sync them.
But since we have tight schedule on the 17.02 release and this issue does cause some example code can't work, so we need to a fix it first, we may consider improve the mechanism later.
Thanks
Qi
next prev parent reply other threads:[~2017-02-13 1:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-09 19:59 Qi Zhang
2017-02-10 10:18 ` Thomas Monjalon
2017-02-13 1:16 ` Zhang, Qi Z [this message]
2017-02-13 21:28 ` Thomas Monjalon
2017-02-14 0:13 ` Zhang, Qi Z
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=039ED4275CED7440929022BC67E706115305B067@SHSMSX103.ccr.corp.intel.com \
--to=qi.z.zhang@intel.com \
--cc=dev@dpdk.org \
--cc=jingjing.wu@intel.com \
--cc=thomas.monjalon@6wind.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).