From: "Zhang, AlvinX" <alvinx.zhang@intel.com>
To: "Guo, Jia" <jia.guo@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "stable@dpdk.org" <stable@dpdk.org>,
"Xing, Beilei" <beilei.xing@intel.com>,
"Jiang, MaoX" <maox.jiang@intel.com>
Subject: Re: [dpdk-dev] [PATCH] net/i40e: fix modifying the number of queues
Date: Mon, 29 Jun 2020 03:16:44 +0000 [thread overview]
Message-ID: <6CE17E955B70FA409286764E3E0B3641164B6906@CDSMSX102.ccr.corp.intel.com> (raw)
In-Reply-To: <83f175ae-9f24-44a6-4cc1-10471152b8f4@intel.com>
Hi Jia,
> -----Original Message-----
> From: Guo, Jia
> Sent: Sunday, June 21, 2020 9:36 PM
> To: Zhang, AlvinX <alvinx.zhang@intel.com>; dev@dpdk.org
> Cc: stable@dpdk.org; Xing, Beilei <beilei.xing@intel.com>; Jiang, MaoX
> <maox.jiang@intel.com>
> Subject: Re: [PATCH] net/i40e: fix modifying the number of queues
>
> hi, alvin
>
> On 6/10/2020 8:07 PM, alvinx.zhang@intel.com wrote:
> > From: Alvin Zhang <alvinx.zhang@intel.com>
> >
> > For the newly created VF, if the number of qps is greater than 4 at
> > startup, it may fail to start. This patch updates the API
> > `i40evf_dev_configure`.
>
>
> Could you explicit explain why it limit to 4 qps, and more detail about below
> code change with the purpose of the patch.
For each VF, the kernel PF driver assign 4 qps when the VF be created.
>
>
> > Fixes: c48eb308ed13 ("net/i40e: support VF request more queues")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Alvin Zhang <alvinx.zhang@intel.com>
> > ---
> > drivers/net/i40e/i40e_ethdev_vf.c | 32 ++++++++++++++++++++++++---
> -----
> > 1 file changed, 24 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
> b/drivers/net/i40e/i40e_ethdev_vf.c
> > index bb5d28a..7500e0a 100644
> > --- a/drivers/net/i40e/i40e_ethdev_vf.c
> > +++ b/drivers/net/i40e/i40e_ethdev_vf.c
> > @@ -1082,13 +1082,10 @@ static int i40evf_dev_xstats_get(struct
> rte_eth_dev *dev,
> > args.out_buffer = vf->aq_resp;
> > args.out_size = I40E_AQ_BUF_SZ;
> >
> > - rte_eal_alarm_cancel(i40evf_dev_alarm_handler, dev);
>
>
> Why interrupt handler is no need to cancel here and more why this change
> is related with this patch according with the commit log?
Here, the handler has been cancecled by the caller.
>
>
> > err = i40evf_execute_vf_cmd(dev, &args);
> > if (err)
> > PMD_DRV_LOG(ERR, "fail to execute command
> OP_REQUEST_QUEUES");
> >
> > - rte_eal_alarm_set(I40EVF_ALARM_INTERVAL,
> > - i40evf_dev_alarm_handler, dev);
> > return err;
> > }
> >
> > @@ -1516,7 +1513,7 @@ static int i40evf_dev_xstats_get(struct
> rte_eth_dev *dev,
> > hw->bus.device = pci_dev->addr.devid;
> > hw->bus.func = pci_dev->addr.function;
> > hw->hw_addr = (void *)pci_dev->mem_resource[0].addr;
> > - hw->adapter_stopped = 0;
> > + hw->adapter_stopped = 1;
>
>
> Why it should be set stopped when init dev?
The Device has not been started until the API ` i40evf_dev_start ` been called.
Here we just initiate the device, so it should be set to 1.
>
>
> > hw->adapter_closed = 0;
> >
> > /* Pass the information to the rte_eth_dev_close() that it should
> also
> > @@ -1612,16 +1609,35 @@ static int eth_i40evf_pci_remove(struct
> rte_pci_device *pci_dev)
> > ad->tx_vec_allowed = true;
> >
> > if (num_queue_pairs > vf->vsi_res->num_queue_pairs) {
> > - int ret = 0;
> > + struct i40e_hw *hw;
> > + int ret;
> >
> > + hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> > PMD_DRV_LOG(INFO, "change queue pairs from %u to %u",
> > vf->vsi_res->num_queue_pairs,
> num_queue_pairs);
> > + if (hw->adapter_stopped == 0) {
> > + PMD_DRV_LOG(WARNING, "Device must be
> stopped first!");
> > + return -EINVAL;
> > + }
> > +
> > + rte_eal_alarm_cancel(i40evf_dev_alarm_handler, dev);
> > ret = i40evf_request_queues(dev, num_queue_pairs);
> > - if (ret != 0)
> > + if (ret)
> > return ret;
> >
> > - ret = i40evf_dev_reset(dev);
> > - if (ret != 0)
> > + /*
> > + * The device must be reinitiated after queue resources
> > + * changed
> > + */
>
>
> Should you check below part is reinitialize process according to exist
> dev_close and dev_init.
Yes, it stops and reinitializes the device , but if call the dev_close to do, some process is no needed and should report errors.
>
>
> > + i40e_shutdown_adminq(hw);
> > + i40evf_disable_irq0(hw);
> > + rte_free(vf->vf_res);
> > + vf->vf_res = NULL;
> > + rte_free(vf->aq_resp);
> > + vf->aq_resp = NULL;
> > +
> > + ret = i40evf_dev_init(dev);
> > + if (ret)
> > return ret;
> > }
> >
next prev parent reply other threads:[~2020-06-29 3:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-10 12:07 alvinx.zhang
2020-06-21 13:36 ` Jeff Guo
2020-06-29 3:16 ` Zhang, AlvinX [this message]
2020-06-30 3:13 ` Jeff Guo
2020-07-02 3:26 ` [dpdk-dev] [PATCH v2] net/i40e: fix modify the number of qps in VF alvinx.zhang
2020-07-15 7:28 ` [dpdk-dev] [PATCH v3] " alvinx.zhang
2020-07-15 10:17 ` Jeff Guo
2020-07-16 1:38 ` Zhang, AlvinX
2020-07-16 1:52 ` [dpdk-dev] [PATCH v4] " alvinx.zhang
2020-07-16 4:24 ` [dpdk-dev] [PATCH v5] " alvinx.zhang
2020-07-16 4:57 ` Yang, Qiming
2020-07-16 5:13 ` Zhang, AlvinX
2020-07-16 5:12 ` alvinx.zhang
2020-07-16 6:33 ` [dpdk-dev] [PATCH v5] net/i40e: fix qps configuration " alvinx.zhang
2020-07-16 7:30 ` Jeff Guo
2020-07-16 9:14 ` 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=6CE17E955B70FA409286764E3E0B3641164B6906@CDSMSX102.ccr.corp.intel.com \
--to=alvinx.zhang@intel.com \
--cc=beilei.xing@intel.com \
--cc=dev@dpdk.org \
--cc=jia.guo@intel.com \
--cc=maox.jiang@intel.com \
--cc=stable@dpdk.org \
/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).