patches for DPDK stable branches
 help / color / mirror / Atom feed
From: "Yu, DapengX" <dapengx.yu@intel.com>
To: "Wu, Jingjing" <jingjing.wu@intel.com>,
	"Xu, Ting" <ting.xu@intel.com>,
	"Zhang, Qi Z" <qi.z.zhang@intel.com>,
	"Xing, Beilei" <beilei.xing@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, "stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-stable] [PATCH] net/iavf: fix vector id assignment
Date: Tue, 12 Jan 2021 07:08:17 +0000	[thread overview]
Message-ID: <5c614223a23046c098f5bcf3c03cedff@intel.com> (raw)
In-Reply-To: <MW3PR11MB4587E9149A7D40F777412BF5E3AA0@MW3PR11MB4587.namprd11.prod.outlook.com>

Hi Jingjing,

I double checked that the max_vectors assignment statement is already ahead of RTE_MIN.
And this patch do the same thing as http://patchwork.dpdk.org/patch/86118/. Since patch 86118 is ahead of this one,  I guess merging 86118 is preferred.

-----Original Message-----
From: Wu, Jingjing 
Sent: Tuesday, January 12, 2021 2:44 PM
To: Xu, Ting <ting.xu@intel.com>; Yu, DapengX <dapengx.yu@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Xing, Beilei <beilei.xing@intel.com>
Cc: dev@dpdk.org; Yu, DapengX <dapengx.yu@intel.com>; stable@dpdk.org
Subject: RE: [PATCH] net/iavf: fix vector id assignment



> -----Original Message-----
> From: Xu, Ting <ting.xu@intel.com>
> Sent: Tuesday, January 12, 2021 2:27 PM
> To: Yu, DapengX <dapengx.yu@intel.com>; Zhang, Qi Z 
> <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>; Xing, 
> Beilei <beilei.xing@intel.com>
> Cc: dev@dpdk.org; Yu, DapengX <dapengx.yu@intel.com>; stable@dpdk.org
> Subject: RE: [PATCH] net/iavf: fix vector id assignment
> 
> > -----Original Message-----
> > From: dapengx.yu@intel.com <dapengx.yu@intel.com>
> > Sent: Friday, January 8, 2021 6:21 PM
> > To: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing 
> > <jingjing.wu@intel.com>; Xing, Beilei <beilei.xing@intel.com>; Xu, 
> > Ting <ting.xu@intel.com>
> > Cc: dev@dpdk.org; Yu, DapengX <dapengx.yu@intel.com>;
> stable@dpdk.org
> > Subject: [PATCH] net/iavf: fix vector id assignment
> >
> > From: YU DAPENG <dapengx.yu@intel.com>
> >
> > The number of MSI-X interrupts on Rx shall be the minimal value of 
> > the number of available MSI-X interrupts per VF - 1 (the 1 is for 
> > miscellaneous
> > interrupt) and the number of configured Rx queues.
> > The current code break the rule because the number of available 
> > MSI-X interrupts is used as the first value, but code does not subtract 1 from it.
> >
> > In normal situation, the first value is larger than the second value.
> > So each queue can be assigned a unique vector_id.
> >
> > For example: 17 available MSI-X interrupts, and 16 available Rx 
> > queues per VF; but only 4 Rx queues are configured when device is started.
> > vector_id:0 is for misc interrupt, vector_id:1 for Rx queue0,
> > vector_id:2 for Rx queue1, vector_id:3 for Rx queue2, vector_id:4 
> > for Rx queue3.
> >
> > Current code breaks the rule in this normal situation, because when 
> > assign vector_ids to interrupt handle, for example, it does not 
> > assign
> > vector_id:4 to the queue3, but assign vector_id:1 to it, because the 
> > condition used causes vector_id wrap around too early.
> >
> 
> Hi, Dapeng,
> 
> Could you please further explain in which condition will this error happen?
> Seems it requires vf->nb_msix = 3 to make it happen, but I do not 
> notice such situation.
> I know it may be an example, is there any more specific case?
> 
> Thanks.
> 
> > In iavf_config_irq_map(), the current code does not write data into 
> > the last element of vecmap[], because of the previous code break.
> > Which cause wrong data is sent to PF with opcode 
> > VIRTCHNL_OP_CONFIG_IRQ_MAP and cause
> > error: VIRTCHNL_STATUS_ERR_PARAM(-5).
> >
> > If kernel driver supports large VFs (up to 256 queues), different 
> > queues can be assigned same vector_id.
> >
> > In order to adapt to large VFs and avoid wrapping early, the 
> > condition is replaced from vec >= vf->nb_msix to vec >= vf->vf_res->max_vectors.
> >
> > Fixes: d6bde6b5eae9 ("net/avf: enable Rx interrupt")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: YU DAPENG <dapengx.yu@intel.com>
> > ---
> >  drivers/net/iavf/iavf_ethdev.c | 8 +++++---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/iavf/iavf_ethdev.c 
> > b/drivers/net/iavf/iavf_ethdev.c index 7e3c26a94..d730bb156 100644
> > --- a/drivers/net/iavf/iavf_ethdev.c
> > +++ b/drivers/net/iavf/iavf_ethdev.c
> > @@ -483,6 +483,7 @@ static int iavf_config_rx_queues_irqs(struct 
> > rte_eth_dev *dev,  struct iavf_qv_map *qv_map;  uint16_t interval, 
> > i;  int vec;
> > +uint16_t max_vectors;
> >
> >  if (rte_intr_cap_multiple(intr_handle) &&
> >      dev->data->dev_conf.intr_conf.rxq) { @@ -570,15 +571,16 @@ 
> > static int iavf_config_rx_queues_irqs(struct rte_eth_dev *dev,
> >  /* If Rx interrupt is reuquired, and we can use
> >   * multi interrupts, then the vec is from 1
> >   */
> > -vf->nb_msix = RTE_MIN(vf->vf_res->max_vectors,
> > -      intr_handle->nb_efd);
> > +max_vectors =
> > +vf->vf_res->max_vectors -
> > IAVF_RX_VEC_START;

Looks it is the same fix as http://patchwork.dpdk.org/patch/86118 /.
I think this line need to be moved to ahead of RTE_MIN? And the RTE_MIN(max_vectors, intr_handle->nb_efd);

> > +vf->nb_msix = RTE_MIN(max_vectors, intr_handle-
> > >nb_efd);
> >  vf->msix_base = IAVF_RX_VEC_START;
> >  vec = IAVF_RX_VEC_START;
> >  for (i = 0; i < dev->data->nb_rx_queues; i++) {  qv_map[i].queue_id 
> > = i;  qv_map[i].vector_id = vec;  intr_handle->intr_vec[i] = vec++; 
> > -if (vec >= vf->nb_msix)
> > +if (vec >= vf->vf_res->max_vectors)
> >  vec = IAVF_RX_VEC_START;
> >  }
> >  vf->qv_map = qv_map;
> > --
> > 2.27.0



  reply	other threads:[~2021-01-12  7:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-30  6:53 dapengx.yu
2020-12-30  7:31 ` [dpdk-stable] [dpdk-dev] " Xie, WeiX
2021-01-04  0:25 ` Zhang, Qi Z
2021-01-04  2:01   ` Yu, DapengX
2021-01-08 10:21 ` [dpdk-stable] " dapengx.yu
2021-01-11  9:06   ` [dpdk-stable] [dpdk-dev] " Xie, WeiX
2021-01-12  6:26   ` [dpdk-stable] " Xu, Ting
2021-01-12  6:44     ` Wu, Jingjing
2021-01-12  7:08       ` Yu, DapengX [this message]
2021-01-12  6:46     ` Yu, DapengX

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=5c614223a23046c098f5bcf3c03cedff@intel.com \
    --to=dapengx.yu@intel.com \
    --cc=beilei.xing@intel.com \
    --cc=dev@dpdk.org \
    --cc=jingjing.wu@intel.com \
    --cc=qi.z.zhang@intel.com \
    --cc=stable@dpdk.org \
    --cc=ting.xu@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).