From: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>
To: "Iremonger, Bernard" <bernard.iremonger@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>,
"Wu, Jingjing" <jingjing.wu@intel.com>
Subject: Re: [dpdk-dev] [PATCH] app/testpmd: fix DCB config issue on ixgbe
Date: Fri, 26 Aug 2016 01:41:37 +0000 [thread overview]
Message-ID: <6A0DE07E22DDAD4C9103DF62FEBC09090349EFA0@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <8CEF83825BEC744B83065625E567D7C21A06A70A@IRSMSX108.ger.corp.intel.com>
Hi Bernard,
> > > >
> > > > The return value of rte_eth_dev_configure() should be checked.
> > > > Calling rte_eth_dev_configure() with parameters nb_rx_q and
> > > > nb_tx_q equal to 0 returns -EINVAL, and does nothing.
> > > > Should the values of nb_rx_q and nb_tx_q be non zero?
> > The 0 is used on purpose. Because I don't want to configure the
> > queues. The only purpose is to make all the configuration to write
> > into the device. And that's why the return value is ignored by (void).
>
> It might be useful to add a comment to explain why rte_eth_dev_configure() is
> being called in this way.
Thanks for the suggestion. I'll add it:)
> > >
> > > If nb_rxq and nb_txq are set to max_rx_queues and max_tx_queues
> > > respectively, there is a failure when the port is started in
> > > ixgbe_check_mq_mode() at line
> > > 1990 in ixgbe_ethdev.c.
> > > SRIOV is active, nb_rx_q=128 nb_tx_q=128 queue number must be less
> > > than or equal to 1.
> > I haven't hit this issue. Would you like to give more details about
> > how to hit it? I'll check if I miss something.
>
> There is a Niantic PF and VF bound to igb_uio. Port 0 is the PF and Port 1 is the
> VF.
> ./testpmd -c 3f -l 1-5 -n 4 -- -i
> testpmd> set corelist 2,3,4,5
> testpmd> port stop 0 /* PF is 0 */
> testpmd> port config 0 dcb vt on 4 pfc on port start 0 /* PF is 0 */
> line 1990 ixgbe_ethdev.c
> SRIOV is active, nb_rx_q=128 nb_tx_q=128 queue number must be less than or
> equal to 1.
> /* Works if nb_rx_q and nb_tx_q set to 1 */
To my opinion, it's a by-design limitation. After using the DCB configuration CLI, the queue number is set to a fix number which is the max number. But as you pointed, when SRIOV is active there's another requirement for the queue number.
We need to investigate deeper and find a solution for it. But I think it's another story. We need another patch for it.
>
> testpmd> show port dcb_tc 0
> ================ DCB infos for port 0 ================
> TC NUMBER: 4 (showing 8 a lot of the time ??) /* port start should be called
> first */
> TC : 0 1 2 3
> Priority : 0 1 2 3
> BW percent : 25% 25% 25% 25%
> RXQ base : 0 1 2 3
> RXQ number : 1 1 1 1
> TXQ base : 0 1 2 3
> TXQ number : 1 1 1 1
> testpmd> show port dcb_tc 1
> Failed to get dcb infos on port 1
>
> > >
> > > nb_rxq and nb_txq are equal to 1 at this point, if they are not
> > > changed, port start completes successfully.
> > >
> > >
> > > > > } else {
> > > > > /*if vt is disabled, use all pf queues */
> > > > > - if (dev_info.vmdq_pool_base == 0) {
> > > > > - nb_rxq = dev_info.max_rx_queues;
> > > > > - nb_txq = dev_info.max_tx_queues;
> > > > > + if (rte_port->dev_info.vmdq_pool_base == 0) {
> > > > > + nb_rxq = rte_port->dev_info.max_rx_queues;
> > > > > + nb_txq = rte_port->dev_info.max_tx_queues;
> > > > > } else {
> > > > > nb_rxq = (queueid_t)num_tcs;
> > > > > nb_txq = (queueid_t)num_tcs; @@ -1997,16 +2010,6
> @@
> > > > > init_port_dcb_config(portid_t pid,
> > > > > }
> > > > > rx_free_thresh = 64;
> > > > >
> > > > > - memset(&port_conf, 0, sizeof(struct rte_eth_conf));
> > > > > - /* Enter DCB configuration status */
> > > > > - dcb_config = 1;
> > > > > -
> > > > > - /*set configuration of DCB in vt mode and DCB in non-vt mode*/
> > > > > - retval = get_eth_dcb_conf(&port_conf, dcb_mode, num_tcs,
> > > > > pfc_en);
> > > > > - if (retval < 0)
> > > > > - return retval;
> > > > > -
> > > > > - rte_port = &ports[pid];
> > > > > memcpy(&rte_port->dev_conf, &port_conf, sizeof(struct
> > > > > rte_eth_conf));
> > > > >
> > > > > rxtx_port_config(rte_port);
> > > > > --
> > > > > 1.9.3
> Regards,
>
> Bernard
next prev parent reply other threads:[~2016-08-26 1:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-05 5:20 Wenzhuo Lu
2016-08-24 9:30 ` Iremonger, Bernard
2016-08-24 15:21 ` Iremonger, Bernard
2016-08-25 1:38 ` Lu, Wenzhuo
2016-08-25 8:39 ` Iremonger, Bernard
2016-08-26 1:41 ` Lu, Wenzhuo [this message]
2016-08-26 10:04 ` Iremonger, Bernard
2016-08-29 2:42 ` Lu, Wenzhuo
2016-09-23 18:24 ` Thomas Monjalon
2016-09-26 0:42 ` Lu, Wenzhuo
2016-09-26 1:11 ` [dpdk-dev] [PATCH v2] app/testpmd: fix DCB config issue Wenzhuo Lu
2016-10-05 10:02 ` Iremonger, Bernard
2016-10-13 15:14 ` Thomas Monjalon
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=6A0DE07E22DDAD4C9103DF62FEBC09090349EFA0@shsmsx102.ccr.corp.intel.com \
--to=wenzhuo.lu@intel.com \
--cc=bernard.iremonger@intel.com \
--cc=dev@dpdk.org \
--cc=jingjing.wu@intel.com \
--cc=pablo.de.lara.guarch@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).