All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Qiu, Michael" <michael.qiu@intel.com>,
	"Zhang, Helin" <helin.zhang@intel.com>,
	"Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [PATCH v2] ixgbe: Fix disable interrupt twice
Date: Fri, 19 Feb 2016 15:14:06 +0000	[thread overview]
Message-ID: <2601191342CEEE43887BDE71AB97725836B0863A@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <533710CFB86FA344BFBF2D6802E6028622F44907@SHSMSX101.ccr.corp.intel.com>

Hi Michael


> 
> On 2016/2/2 19:03, Ananyev, Konstantin wrote:
> >
> 
> [...]
> 
> >>>> I don't think i40e miss it, because it not the right please to disable interrupt.
> >>>> because all interrupts are enabled in init stage.
> >>>>
> >>>> Actually, ixgbe enable the interrupt in init stage, but in dev_start, it disable it
> >>>> first and re-enable, so it just the same with doing nothing about interrupt.
> >>>>
> >>>> Just think below:
> >>>>
> >>>> 1. start the port.(interrupt already enabled in init stage, disable -->
> >>>> re-enable)
> >>>> 2. stop the port.(disable interrupt)
> >>>> 3. start port again(Try to disable, but failed, already disabled)
> >>>>
> >>>> Would you think the code has issue?
> >>> [Zhang, Helin] in ixgbe PMD, it can be seen that uninit() calls dev_close(),
> >>> which calls dev_stop(). So I think the disabling can be done only in dev_stop().
> >>> All others can make use of dev_stop to disable the interrupt.
> >> As I said, if it is in dev_stop, it will has issue when dev_start -->
> >> dev_stop --> dev_start, this also could applied in i40e and fm10k. If
> >> you want to put it in dev_stop, better to remove enable interrupts in
> >> init stage, and only put it in dev_start.
> > We can't remove enabling interrupt at init stage and put it only in dev_start().
> > That means PF couldn't handle interrupts from VF till dev_start() will be executed on PF
> >  - which could never happen.
> > For same reason we can't disable all interrupts in dev_stop().
> > See: http://dpdk.org/ml/archives/dev/2015-November/027238.html
> 
> Hi, Konstantin
> 
> Yes, you are right.
> 
> So the only way to fix this issue should remove it in dev_stop(), and
> left it in uinit() stage, which my patch does.
> 
> Am I right?

Yes, I think so.
PF should be able to receive MBOX interrupts  after dev_stop().
Konstantin

> 
> Thanks,
> Michael
> > Konstantin
> >
> >> Thanks,
> >> Michael
> >>> Regards,
> >>> Helin
> >>>
> >>>> Thanks,
> >>>> Michael
> >>>>
> >>>>> Maybe we can follow fm10k's style.
> >>>>>
> >>>>>> On other hand, if we remove it in dev_stop, any side effect? In ixgbe
> >>>>>> start, it will always disable it first and then re-enable it, so it's safe.
> >>>>> I think you mean we can disable intr anyway even if it has been disabled.
> >>>> Actually, we couldn't, DPDK call VFIO ioctl to kernel to disable interrupts, and
> >>>> if we try disable twice, it will return and error.
> >>>> That's why I mean we need a flag to show the interrupts stats. If it already
> >>>> disabled, we do not need call in to kernel. just return and give a warning
> >>>> message.
> >>>>
> >>>> Thanks,
> >>>> Michael
> >>>>
> >>>>>  Sounds more like why we don't
> >>>>> need this patch :)
> >>>>>
> >>>>>> Thanks,
> >>>>>> Michael
> >

  reply	other threads:[~2016-02-19 15:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-29  5:51 [PATCH] ixgbe: Fix disable interrupt twice Michael Qiu
2016-01-29  5:58 ` [PATCH v2] " Michael Qiu
2016-01-29  8:07   ` Lu, Wenzhuo
2016-02-01  8:05     ` Qiu, Michael
2016-02-02  1:03       ` Lu, Wenzhuo
2016-02-02  2:06         ` Qiu, Michael
2016-02-02  2:14           ` Zhang, Helin
2016-02-02  2:57             ` Qiu, Michael
2016-02-02  3:07               ` Zhang, Helin
2016-02-02  3:15                 ` Qiu, Michael
2016-02-02 11:03               ` Ananyev, Konstantin
2016-02-19  8:07                 ` Qiu, Michael
2016-02-19 15:14                   ` Ananyev, Konstantin [this message]
2016-02-02  2:26           ` Lu, Wenzhuo
2016-02-23  2:10   ` Zhang, Helin
2016-02-26 14:39     ` Bruce Richardson

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=2601191342CEEE43887BDE71AB97725836B0863A@irsmsx105.ger.corp.intel.com \
    --to=konstantin.ananyev@intel.com \
    --cc=dev@dpdk.org \
    --cc=helin.zhang@intel.com \
    --cc=michael.qiu@intel.com \
    --cc=wenzhuo.lu@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.