DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Zhang, Helin" <helin.zhang@intel.com>
To: "Zhang, Qi Z" <qi.z.zhang@intel.com>,
	"Lu, Wenzhuo" <wenzhuo.lu@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix interrupt block issue
Date: Tue, 17 Jan 2017 01:31:29 +0000	[thread overview]
Message-ID: <F35DEAC7BCE34641BA9FAC6BCA4A12E71A99BD27@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <1484589732-13537-1-git-send-email-qi.z.zhang@intel.com>



> -----Original Message-----
> From: Zhang, Qi Z
> Sent: Tuesday, January 17, 2017 2:02 AM
> To: Lu, Wenzhuo; Zhang, Helin
> Cc: dev@dpdk.org; Zhang, Qi Z
> Subject: [PATCH v2] net/ixgbe: fix interrupt block issue
> 
> When handle link status change interrupt, interrupt will be blocked until
> delayed handler finish, the duration is at least 1 second, this may cause
> following VF to PF mailbox traffic be blocked and sometimes PF can't ack to
> VF in time before VF think it's time out.
> This patch remove this limitation, interrupt will be enabled before interrupt
> handler finish, and a flag is used to prevent re-entering delayed handler.
> 
> Fixes: 0a45657a6794 ("pci: rework interrupt handling")
> 
> Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
> ---
> v2:
> - rebase to dpdk-next-net
> 
>  drivers/net/ixgbe/ixgbe_ethdev.c | 19 +++++++++----------
> drivers/net/ixgbe/ixgbe_ethdev.h |  2 ++
>  2 files changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index c66f432..f36ce89 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -3762,7 +3762,6 @@ ixgbe_dev_interrupt_action(struct rte_eth_dev
> *dev,
>  		IXGBE_DEV_PRIVATE_TO_INTR(dev->data->dev_private);
>  	int64_t timeout;
>  	struct rte_eth_link link;
> -	int intr_enable_delay = false;
>  	struct ixgbe_hw *hw =
>  		IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> 
> @@ -3778,7 +3777,7 @@ ixgbe_dev_interrupt_action(struct rte_eth_dev
> *dev,
>  		intr->flags &= ~IXGBE_FLAG_PHY_INTERRUPT;
>  	}
> 
> -	if (intr->flags & IXGBE_FLAG_NEED_LINK_UPDATE) {
> +	if (intr->flags & IXGBE_FLAG_NEED_LINK_UPDATE && !intr->delay) {
>  		/* get the link status before link update, for predicting later
> */
>  		memset(&link, 0, sizeof(link));
>  		rte_ixgbe_dev_atomic_read_link_status(dev, &link); @@ -
> 3795,20 +3794,16 @@ ixgbe_dev_interrupt_action(struct rte_eth_dev *dev,
>  			timeout = IXGBE_LINK_DOWN_CHECK_TIMEOUT;
> 
>  		ixgbe_dev_link_status_print(dev);
> +		intr->delay = true;
> 
> -		intr_enable_delay = true;
> -	}
> -
> -	if (intr_enable_delay) {
>  		if (rte_eal_alarm_set(timeout * 1000,
>  				      ixgbe_dev_interrupt_delayed_handler,
> (void *)dev) < 0)
>  			PMD_DRV_LOG(ERR, "Error setting alarm");
> -	} else {
> -		PMD_DRV_LOG(DEBUG, "enable intr immediately");
> -		ixgbe_enable_intr(dev);
> -		rte_intr_enable(intr_handle);
>  	}
> 
> +	PMD_DRV_LOG(DEBUG, "enable intr immediately");
> +	ixgbe_enable_intr(dev);
> +	rte_intr_enable(intr_handle);
I think we should still disable LSC interrupt before the delayed handling, to
avoid any chaos on potential too many interrupts being reported.
Of cause other interrupts can be enabled here, to fix the issue you found.

Thanks,
Helin

> 
>  	return 0;
>  }
> @@ -3839,6 +3834,8 @@ ixgbe_dev_interrupt_delayed_handler(void
> *param)
>  		IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
>  	uint32_t eicr;
> 
> +	ixgbe_disable_intr(hw);
> +
>  	eicr = IXGBE_READ_REG(hw, IXGBE_EICR);
>  	if (eicr & IXGBE_EICR_MAILBOX)
>  		ixgbe_pf_mbx_process(dev);
> @@ -3861,6 +3858,8 @@ ixgbe_dev_interrupt_delayed_handler(void
> *param)
>  		intr->flags &= ~IXGBE_FLAG_MACSEC;
>  	}
> 
> +	intr->delay = false;
> +
>  	PMD_DRV_LOG(DEBUG, "enable intr in delayed handler S[%08x]",
> eicr);
>  	ixgbe_enable_intr(dev);
>  	rte_intr_enable(intr_handle);
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h
> b/drivers/net/ixgbe/ixgbe_ethdev.h
> index 6695b68..b931108 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.h
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.h
> @@ -200,6 +200,8 @@ struct ixgbe_hw_fdir_info {  struct ixgbe_interrupt {
>  	uint32_t flags;
>  	uint32_t mask;
> +	/* to prevent re-enter delayed handler */
> +	uint8_t delay;
Use bool to replace uint8_t?

Thanks,
Helin

>  };
> 
>  struct ixgbe_stat_mapping_registers {
> --
> 2.7.4

  reply	other threads:[~2017-01-17  1:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-16 18:02 Qi Zhang
2017-01-17  1:31 ` Zhang, Helin [this message]
2017-01-17  2:16   ` 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=F35DEAC7BCE34641BA9FAC6BCA4A12E71A99BD27@SHSMSX103.ccr.corp.intel.com \
    --to=helin.zhang@intel.com \
    --cc=dev@dpdk.org \
    --cc=qi.z.zhang@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 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).