From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Zhang, Qi Z" <qi.z.zhang@intel.com>,
"thomas@monjalon.net" <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"Xing, Beilei" <beilei.xing@intel.com>,
"Wu, Jingjing" <jingjing.wu@intel.com>,
"Lu, Wenzhuo" <wenzhuo.lu@intel.com>
Subject: Re: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue setup
Date: Fri, 16 Mar 2018 18:47:32 +0000 [thread overview]
Message-ID: <2601191342CEEE43887BDE71AB977258A0AB0E67@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <039ED4275CED7440929022BC67E706115316E814@SHSMSX103.ccr.corp.intel.com>
> -----Original Message-----
> From: Zhang, Qi Z
> Sent: Friday, March 16, 2018 2:15 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; thomas@monjalon.net
> Cc: dev@dpdk.org; Xing, Beilei <beilei.xing@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>
> Subject: RE: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue setup
>
>
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qi
> > > > > > > > > > Zhang
> > > > > > > > > > Sent: Friday, March 2, 2018 4:13 AM
> > > > > > > > > > To: thomas@monjalon.net
> > > > > > > > > > Cc: dev@dpdk.org; Xing, Beilei <beilei.xing@intel.com>;
> > > > > > > > > > Wu, Jingjing <jingjing.wu@intel.com>; Lu, Wenzhuo
> > > > > > > > > > <wenzhuo.lu@intel.com>; Zhang,
> > > > > > > > > Qi
> > > > > > > > > > Z <qi.z.zhang@intel.com>
> > > > > > > > > > Subject: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable
> > > > > > > > > > deferred queue setup
> > > > > > > > > >
> > > > > > > > > > Expose the deferred queue configuration capability and
> > > > > > > > > > enhance i40e_dev_[rx|tx]_queue_[setup|release] to handle
> > > > > > > > > > the situation when device already started.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
> > > > > > > > > > ---
> > > > > > > > > > drivers/net/i40e/i40e_ethdev.c | 6 ++++
> > > > > > > > > > drivers/net/i40e/i40e_rxtx.c | 62
> > > > > > > > > ++++++++++++++++++++++++++++++++++++++++--
> > > > > > > > > > 2 files changed, 66 insertions(+), 2 deletions(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > > > > > > > > > b/drivers/net/i40e/i40e_ethdev.c index
> > > > > > > > > > 06b0f03a1..843a0c42a
> > > > > > > > > > 100644
> > > > > > > > > > --- a/drivers/net/i40e/i40e_ethdev.c
> > > > > > > > > > +++ b/drivers/net/i40e/i40e_ethdev.c
> > > > > > > > > > @@ -3195,6 +3195,12 @@ i40e_dev_info_get(struct
> > > > > > > > > > rte_eth_dev
> > > > > > > *dev,
> > > > > > > > > struct rte_eth_dev_info *dev_info)
> > > > > > > > > > DEV_TX_OFFLOAD_GRE_TNL_TSO |
> > > > > > > > > > DEV_TX_OFFLOAD_IPIP_TNL_TSO |
> > > > > > > > > > DEV_TX_OFFLOAD_GENEVE_TNL_TSO;
> > > > > > > > > > + dev_info->deferred_queue_config_capa =
> > > > > > > > > > + DEV_DEFERRED_RX_QUEUE_SETUP |
> > > > > > > > > > + DEV_DEFERRED_TX_QUEUE_SETUP |
> > > > > > > > > > + DEV_DEFERRED_RX_QUEUE_RELEASE |
> > > > > > > > > > + DEV_DEFERRED_TX_QUEUE_RELEASE;
> > > > > > > > > > +
> > > > > > > > > > dev_info->hash_key_size =
> > > (I40E_PFQF_HKEY_MAX_INDEX +
> > > > > 1) *
> > > > > > > > > > sizeof(uint32_t);
> > > > > > > > > > dev_info->reta_size = pf->hash_lut_size; diff --git
> > > > > > > > > > a/drivers/net/i40e/i40e_rxtx.c
> > > > > > > > > > b/drivers/net/i40e/i40e_rxtx.c index
> > > > > > > > > > 1217e5a61..e5f532cf7 100644
> > > > > > > > > > --- a/drivers/net/i40e/i40e_rxtx.c
> > > > > > > > > > +++ b/drivers/net/i40e/i40e_rxtx.c
> > > > > > > > > > @@ -1712,6 +1712,7 @@ i40e_dev_rx_queue_setup(struct
> > > > > > > rte_eth_dev
> > > > > > > > > *dev,
> > > > > > > > > > uint16_t len, i;
> > > > > > > > > > uint16_t reg_idx, base, bsf, tc_mapping;
> > > > > > > > > > int q_offset, use_def_burst_func = 1;
> > > > > > > > > > + int ret = 0;
> > > > > > > > > >
> > > > > > > > > > if (hw->mac.type == I40E_MAC_VF || hw->mac.type ==
> > > > > > > > > I40E_MAC_X722_VF) {
> > > > > > > > > > vf =
> > > > > I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
> > > > > > > > > > @@ -1841,6 +1842,25 @@ i40e_dev_rx_queue_setup(struct
> > > > > > > rte_eth_dev
> > > > > > > > > *dev,
> > > > > > > > > > rxq->dcb_tc = i;
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > + if (dev->data->dev_started) {
> > > > > > > > > > + ret = i40e_rx_queue_init(rxq);
> > > > > > > > > > + if (ret != I40E_SUCCESS) {
> > > > > > > > > > + PMD_DRV_LOG(ERR,
> > > > > > > > > > + "Failed to do RX queue initialization");
> > > > > > > > > > + return ret;
> > > > > > > > > > + }
> > > > > > > > > > + if (ad->rx_vec_allowed)
> > > > > > > > >
> > > > > > > > > Better to check what rx function is installed right now.
> > > > > > > > Yes, it should be fixed, need to return fail if any conflict
> > > > > > > > >
> > > > > > > > > > + i40e_rxq_vec_setup(rxq);
> > > > > > > > > > + if (!rxq->rx_deferred_start) {
> > > > > > > > > > + ret = i40e_dev_rx_queue_start(dev,
> > queue_idx);
> > > > > > > > >
> > > > > > > > > I don't think it is a good idea to start/stop queue inside
> > > > > > > > > queue_setup/queue_release.
> > > > > > > > > There is special API (queue_start/queue_stop) to do this.
> > > > > > > >
> > > > > > > > The idea is if dev already started, the queue is supposed to
> > > > > > > > be started
> > > > > > > automatically after queue_setup.
> > > > > > >
> > > > > > > Why is that?
> > > > > > Because device is already started, its like a running conveyor
> > > > > > belt, anything
> > > > > you put or replace on it just moves automatically.
> > > > >
> > > > > Why is that? :)
> > > > > You do break existing behavior.
> > > > > Right now it possible to do:
> > > > > queue_setup(); queue_setup();
> > > > > for the same queue.
> > > > > With you patch is not any more
> > > > Why not?
> > > > I think with my patch,
> > > > It assumes we can run below scenario on the same queue.
> > > > (note, I assume queue_stop/start has been moved from i40e to ethedev
> > > > layer already.) queue_setup + queue_setup + dev_start + queue_setup
> > > > + queue_setup,
> > >
> > > Because you can't do queue_setup() on already started queue.
> > > So if you do start() inside setup() second setup() should fail.
> > NO, because in queue_release, it will call queue_stop And as I said before, it's
> > better to move to queue_stop in ether layer, it's not an issue.
> > >
> > > > queue_stop/start are handled inside queue_setup automatically after
> > > dev_started?
> > >
> > > Again - I don't see any advantages to change existing API behavior and
> > > introduce implicit start/stop inside setup.
> > > It only introduce extra confusion for the users.
> > > So I still think we better keep existing behavior.
> > > Konstantin
> >
> > OK, let me try again :)
> > I think the patch try to keep deferred setup independent of deferred start
> > Deferred setup does not necessary to imply a deferred start.
I don't understand what means 'deferred setup'.
We do have deferred_start for queue config, but it only used by dev_start().
Please, stop imply anything.
We have an API which is quite straightforward and does exactly what it states.
- queue_setup() - if queue is not started, then setup the queue.
- queue_start() - if queue is not started, then start the queue.
- queue_stop() - if queue is started, then stop the queue.
- dev_start() - in terms of queue behavior
for all configured queues; do
if queue->deferred_start != 0; then queue_start(queue);
done
Let's keep it like that - nice and simple.
No need to introduce such no-sense as 'deferred setup' or implicit stop in start.
That just would add more mess and confusion.
> > Which means
> > Queue_setup + dev_start = dev_start + queue_setup
> > Queue_setup(deferred) + dev_start + queue_start = dev_start +
> > queue_setup(deferred) + queue_start.
> > Queue_setup + dev_start + queue_setup(same queue) = dev_start +
> > queue_setup + queue_setup(same queue)
> >
>
> One mistake for the third item, It should be
> Queue_setup + Queue_setup(same queue) + dev_start = queue_setup + dev_start + queue_setup(same queue)
>
> > But not
> > Queue_setup + dev_start = dev_start+ queue_setup + queue_start
> > Queue_setup(deffered) + dev_start +qeueu_start = dev_start+ queue_setup
> > (ignore deferred)+ queue_start Queue_setup + dev_start +
> > queue_setup(same queue) = dev_start + queue_setup + queue_stop +
> > queue_setup + queue_start.
>
> Third item should be
> Queue_setup + Queue_setup(same queue) + dev_start = queue_setup + dev_start + queue_stop + queue_setup(same queue) + queue_start
> >
> > I think option 1 have the pattern and easy to understand
I don't think so.
>From my perspective it just introduce more confusion to the user.
> and option2 just add unnecessary queue_start/queue_stop
Why unnecessary - if the user wants to start the queue - he/she calls queue_start(),
It is obvious, isn't it?
> and make deferred_start redundant at some situation.
Deferred start is used only by dev_start, that's what it was intended for.
Let it stay that way.
BTW, we can get rid of it and add to dev_start() as a parameter
a list of queues to start (not to start) - would be great.
But that's the matter of different discussion, I think.
Konstantin
> > >
> > > > .
> > > > > And I don't see an good reason to break existing behavior.
> > I don't think it break any exist behavior, again deferred setup does not imply
> > deferred start, because dev_start imply queue_start, and we follow this logic.
> >
> > > > > What is the advantage of implicit call queue_start() implicitly
> > > > > from the queue_setup()/?
> > > > > Konstantin
> > > > >
> > > > > >
> > > > > > > Might be user doesn't want to start queue, might be he only
> > > > > > > wants to start it.
> > > > > > Use deferred_start_flag,
> > > > > > > Might be he would need to call queue_setup() once again later
> > > > > > > before starting it - based on some logic?
> > > > > > Dev_ops->queue_stop will be called first before
> > > > > > dev_ops->queue_setup in
> > > > > rte_eth_rx|tx_queue_setup, if a queue is running.
> > > > > >
> > > > > >
> > > > > >
> > > > > > > If the user wants to setup and start the queue immediately he
> > > > > > > can always
> > > > > do:
> > > > > > >
> > > > > > > rc = queue_setup(...);
> > > > > > > if (rc == 0)
> > > > > > > queue_start(...);
> > > > > >
> > > > > > application no need to call queue_start explicitly in this case.
> > > > > >
> > > > > > >
> > > > > > > We have a pretty well defined API here let's keep it like that.
> > > > > > > Konstantin
next prev parent reply other threads:[~2018-03-16 18:47 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-12 4:53 [dpdk-dev] [PATCH 0/4] " Qi Zhang
2018-02-12 4:53 ` [dpdk-dev] [PATCH 1/4] ether: support " Qi Zhang
2018-02-12 13:55 ` Thomas Monjalon
2018-02-12 4:53 ` [dpdk-dev] [PATCH 2/4] app/testpmd: add parameters for " Qi Zhang
2018-02-12 4:53 ` [dpdk-dev] [PATCH 3/4] app/testpmd: add command for " Qi Zhang
2018-02-12 4:53 ` [dpdk-dev] [PATCH 4/4] net/i40e: enable deferred " Qi Zhang
2018-03-02 4:13 ` [dpdk-dev] [PATCH v2 0/4] " Qi Zhang
2018-03-02 4:13 ` [dpdk-dev] [PATCH v2 1/4] ether: support " Qi Zhang
2018-03-14 12:31 ` Ananyev, Konstantin
2018-03-15 3:13 ` Zhang, Qi Z
2018-03-15 13:16 ` Ananyev, Konstantin
2018-03-15 15:08 ` Zhang, Qi Z
2018-03-15 15:38 ` Ananyev, Konstantin
2018-03-16 0:42 ` Zhang, Qi Z
2018-03-02 4:13 ` [dpdk-dev] [PATCH v2 2/4] app/testpmd: add parameters for " Qi Zhang
2018-03-14 17:38 ` Ananyev, Konstantin
2018-03-15 3:58 ` Zhang, Qi Z
2018-03-15 13:42 ` Ananyev, Konstantin
2018-03-15 14:31 ` Zhang, Qi Z
2018-03-02 4:13 ` [dpdk-dev] [PATCH v2 3/4] app/testpmd: add command for " Qi Zhang
2018-03-14 17:36 ` Ananyev, Konstantin
2018-03-14 17:41 ` Ananyev, Konstantin
2018-03-15 3:59 ` Zhang, Qi Z
2018-03-02 4:13 ` [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred " Qi Zhang
2018-03-14 12:35 ` Ananyev, Konstantin
2018-03-15 3:22 ` Zhang, Qi Z
2018-03-15 3:50 ` Zhang, Qi Z
2018-03-15 13:22 ` Ananyev, Konstantin
2018-03-15 14:30 ` Zhang, Qi Z
2018-03-15 15:22 ` Ananyev, Konstantin
2018-03-16 0:52 ` Zhang, Qi Z
2018-03-16 9:54 ` Ananyev, Konstantin
2018-03-16 11:00 ` Bruce Richardson
2018-03-16 13:18 ` Zhang, Qi Z
2018-03-16 14:15 ` Zhang, Qi Z
2018-03-16 18:47 ` Ananyev, Konstantin [this message]
2018-03-18 7:55 ` Zhang, Qi Z
2018-03-20 13:18 ` Ananyev, Konstantin
2018-03-21 1:53 ` Zhang, Qi Z
2018-03-21 7:28 ` [dpdk-dev] [PATCH v3 0/3] runtime " Qi Zhang
2018-03-21 7:28 ` [dpdk-dev] [PATCH v3 1/3] ether: support " Qi Zhang
2018-03-25 19:47 ` Ananyev, Konstantin
2018-03-21 7:28 ` [dpdk-dev] [PATCH v3 2/3] app/testpmd: add command for " Qi Zhang
2018-03-21 7:28 ` [dpdk-dev] [PATCH v3 3/3] net/i40e: enable runtime " Qi Zhang
2018-03-25 19:46 ` Ananyev, Konstantin
2018-03-26 8:49 ` Zhang, Qi Z
2018-03-26 8:59 ` [dpdk-dev] [PATCH v4 0/3] " Qi Zhang
2018-03-26 8:59 ` [dpdk-dev] [PATCH v4 1/3] ether: support " Qi Zhang
2018-03-26 8:59 ` [dpdk-dev] [PATCH v4 2/3] app/testpmd: add command for " Qi Zhang
2018-04-01 12:21 ` Ananyev, Konstantin
2018-03-26 8:59 ` [dpdk-dev] [PATCH v4 3/3] net/i40e: enable runtime " Qi Zhang
2018-04-01 12:18 ` Ananyev, Konstantin
2018-04-02 2:20 ` Zhang, Qi Z
2018-04-02 2:59 ` [dpdk-dev] [PATCH v5 0/3] " Qi Zhang
2018-04-02 2:59 ` [dpdk-dev] [PATCH v5 1/3] ether: support " Qi Zhang
2018-04-06 19:42 ` Rosen, Rami
2018-04-08 2:20 ` Zhang, Qi Z
2018-04-02 2:59 ` [dpdk-dev] [PATCH v5 2/3] app/testpmd: add command for " Qi Zhang
2018-04-07 15:49 ` Rosen, Rami
2018-04-08 2:22 ` Zhang, Qi Z
2018-04-02 2:59 ` [dpdk-dev] [PATCH v5 3/3] net/i40e: enable runtime " Qi Zhang
2018-04-02 23:36 ` [dpdk-dev] [PATCH v5 0/3] " Ananyev, Konstantin
2018-04-08 2:42 ` Qi Zhang
2018-04-08 2:42 ` [dpdk-dev] [PATCH v6 1/3] ether: support " Qi Zhang
2018-04-10 13:59 ` Thomas Monjalon
2018-04-20 11:14 ` Ferruh Yigit
2018-04-24 19:36 ` Thomas Monjalon
2018-04-25 5:33 ` Zhang, Qi Z
2018-04-25 7:54 ` Thomas Monjalon
2018-04-20 11:16 ` Ferruh Yigit
2018-04-08 2:42 ` [dpdk-dev] [PATCH v6 2/3] app/testpmd: add command for " Qi Zhang
2018-04-20 11:29 ` Ferruh Yigit
2018-04-22 11:57 ` Zhang, Qi Z
2018-04-08 2:42 ` [dpdk-dev] [PATCH v6 3/3] net/i40e: enable runtime " Qi Zhang
2018-04-20 11:17 ` Ferruh Yigit
2018-04-22 11:58 ` [dpdk-dev] [PATCH v7 0/5] " Qi Zhang
2018-04-22 11:58 ` [dpdk-dev] [PATCH v7 1/5] ethdev: support " Qi Zhang
2018-04-23 17:45 ` Ferruh Yigit
2018-04-22 11:58 ` [dpdk-dev] [PATCH v7 2/5] app/testpmd: add command for " Qi Zhang
2018-04-22 11:58 ` [dpdk-dev] [PATCH v7 3/5] app/testpmd: enable per queue configure Qi Zhang
2018-04-23 17:45 ` Ferruh Yigit
2018-04-22 11:58 ` [dpdk-dev] [PATCH v7 4/5] app/testpmd: enable queue ring size configure Qi Zhang
2018-04-23 17:45 ` Ferruh Yigit
2018-04-24 3:16 ` Zhang, Qi Z
2018-04-24 11:05 ` Ferruh Yigit
2018-04-22 11:58 ` [dpdk-dev] [PATCH v7 5/5] net/i40e: enable runtime queue setup Qi Zhang
2018-04-23 17:45 ` [dpdk-dev] [PATCH v7 0/5] " Ferruh Yigit
2018-04-24 12:44 ` [dpdk-dev] [PATCH v8 " Qi Zhang
2018-04-24 12:44 ` [dpdk-dev] [PATCH v8 1/5] ethdev: support " Qi Zhang
2018-04-24 14:01 ` Thomas Monjalon
2018-04-24 12:44 ` [dpdk-dev] [PATCH v8 2/5] app/testpmd: add command for " Qi Zhang
2018-04-24 12:44 ` [dpdk-dev] [PATCH v8 3/5] app/testpmd: enable per queue configure Qi Zhang
2018-04-24 12:44 ` [dpdk-dev] [PATCH v8 4/5] app/testpmd: enable queue ring size configure Qi Zhang
2018-04-24 12:44 ` [dpdk-dev] [PATCH v8 5/5] net/i40e: enable runtime queue setup Qi Zhang
2018-04-24 14:50 ` [dpdk-dev] [PATCH v8 0/5] " Ferruh Yigit
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=2601191342CEEE43887BDE71AB977258A0AB0E67@irsmsx105.ger.corp.intel.com \
--to=konstantin.ananyev@intel.com \
--cc=beilei.xing@intel.com \
--cc=dev@dpdk.org \
--cc=jingjing.wu@intel.com \
--cc=qi.z.zhang@intel.com \
--cc=thomas@monjalon.net \
--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).