All of lore.kernel.org
 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-dev] [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 [dpdk-dev] [PATCH] net/iavf: fix vector id assignment dapengx.yu
2020-12-30  7:31 ` Xie, WeiX
2021-01-04  0:25 ` Zhang, Qi Z
2021-01-04  2:01   ` Yu, DapengX
2021-01-08 10:21 ` dapengx.yu
2021-01-11  9:06   ` Xie, WeiX
2021-01-12  6:26   ` 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 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.