From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id CE778271 for ; Wed, 21 Mar 2018 02:53:35 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Mar 2018 18:53:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,338,1517904000"; d="scan'208";a="36747212" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga003.jf.intel.com with ESMTP; 20 Mar 2018 18:53:34 -0700 Received: from fmsmsx116.amr.corp.intel.com (10.18.116.20) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 20 Mar 2018 18:53:34 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by fmsmsx116.amr.corp.intel.com (10.18.116.20) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 20 Mar 2018 18:53:33 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.235]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.226]) with mapi id 14.03.0319.002; Wed, 21 Mar 2018 09:53:31 +0800 From: "Zhang, Qi Z" To: "Ananyev, Konstantin" CC: "dev@dpdk.org" , "Xing, Beilei" , "Wu, Jingjing" , "Lu, Wenzhuo" Thread-Topic: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue setup Thread-Index: AQHTsdzQOpLcPZjlYEiAhjWXFitx2KPPOCyAgAF7dxCAACPogIAAkFrA//+RIACAASKVMIAAE/2AgAC3wZCAABZaYP//xvMAgALeSMCAAw8xgIABTwgA Date: Wed, 21 Mar 2018 01:53:31 +0000 Message-ID: <039ED4275CED7440929022BC67E70611531704AB@SHSMSX103.ccr.corp.intel.com> References: <20180212045314.171616-1-qi.z.zhang@intel.com> <20180302041306.90324-1-qi.z.zhang@intel.com> <20180302041306.90324-5-qi.z.zhang@intel.com> <2601191342CEEE43887BDE71AB9772589E28FA78@irsmsx105.ger.corp.intel.com> <039ED4275CED7440929022BC67E706115316DF28@SHSMSX103.ccr.corp.intel.com> <2601191342CEEE43887BDE71AB9772589E290215@irsmsx105.ger.corp.intel.com> <039ED4275CED7440929022BC67E706115316E22A@SHSMSX103.ccr.corp.intel.com> <2601191342CEEE43887BDE71AB9772589E2902C2@irsmsx105.ger.corp.intel.com> <039ED4275CED7440929022BC67E706115316E439@SHSMSX103.ccr.corp.intel.com> <2601191342CEEE43887BDE71AB977258A0AB09AC@irsmsx105.ger.corp.intel.com> <039ED4275CED7440929022BC67E706115316E814@SHSMSX103.ccr.corp.intel.com> <2601191342CEEE43887BDE71AB977258A0AB0E67@irsmsx105.ger.corp.intel.com> <039ED4275CED7440929022BC67E706115316EDD8@SHSMSX103.ccr.corp.intel.com> <2601191342CEEE43887BDE71AB977258A0AB217E@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB977258A0AB217E@irsmsx105.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue setup X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 01:53:36 -0000 > -----Original Message----- > From: Ananyev, Konstantin > Sent: Tuesday, March 20, 2018 9:19 PM > To: Zhang, Qi Z > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing > ; Lu, Wenzhuo > Subject: RE: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue > setup >=20 >=20 >=20 > > > > > > > > > > > > > > > > > > > > > > > > > > Expose the deferred queue configuration > > > > > > > > > > > > > capability and enhance > > > > > > > > > > > > > i40e_dev_[rx|tx]_queue_[setup|release] > > > > > > > > > > > > > to handle the situation when device already start= ed. > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Qi Zhang > > > > > > > > > > > > > --- > > > > > > > > > > > > > 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 =3D > > > > > > > > > > > > > + 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 =3D > > > > > > (I40E_PFQF_HKEY_MAX_INDEX + > > > > > > > > 1) * > > > > > > > > > > > > > sizeof(uint32_t); > > > > > > > > > > > > > dev_info->reta_size =3D 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 =3D 1; > > > > > > > > > > > > > + int ret =3D 0; > > > > > > > > > > > > > > > > > > > > > > > > > > if (hw->mac.type =3D=3D I40E_MAC_VF || > > > > > > > > > > > > > hw->mac.type > > > =3D=3D > > > > > > > > > > > > I40E_MAC_X722_VF) { > > > > > > > > > > > > > vf =3D > > > > > > > > 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 =3D i; > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > + if (dev->data->dev_started) { > > > > > > > > > > > > > + ret =3D i40e_rx_queue_init(rxq); > > > > > > > > > > > > > + if (ret !=3D 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 =3D 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 defer= red > 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 !=3D 0; then queue_start(queue); > > > done > > > > > > Let's keep it like that - nice and simple. > > Yes, let's keep it nice and simple at dev_ops layer,. > > But etherdev layer should be more friendly to application, we need impl= y > something. > > > > For example, why we don't expose queue_release to ether layer, Why > > queue_setup imply a queue_release on a queue already be setup? > > Shouldn't it return fail to warn user, that a queue can't be reconfigur= e > without release if first? >=20 > If you think queue_release() should be a public API - submit and RFC for = that, > then we can discuss it. >=20 > > > > I thinks it's the same pattern for why we have queue_stop / queue_start > here. >=20 > Not really from my perspective. > setup/release - to setup/teardown internal queue structures. > start/stop - to start/stop RX/TX on that queues. >=20 > > if application want to setup a queue on a running device, of cause it > > want queue be started immediately >=20 > Some apps might, some might not. > Those who want to start the queue will call queue_start() - simple and > straightforward. >=20 > > (if not? It can use deferred_start) >=20 > rte_eth_rxconf.deferred_start right now is used by one particular purpose= : > uint8_t rx_deferred_start; /**< Do not start queue with rte_eth_dev_start= (). > */ >=20 > Now you are trying to overload it with extra meaning: Yes, based on exist comment, deferred_start is overloaded. > Do not start queue with rte_eth_dev_start() if device is already started = don't > start the queue from the queue_setup(). This is correct but also could be explained in a simple way. deferred_start=3D0: queue will be started automatically when device is star= ted. deferred_start=3D1: queue can only be started by queue_start manually.=20 maybe "no_auto_start" could be a better name. >=20 > Looks very confusing to me, plus what is probably worse there is now no > consistent behavior between queue_setup() invoked before dev_start() and > queue_setup() invoked after dev_start. > I would expect queue_setup() in both cases to preserve current behavior o= r > at least be as close as possible to it. >=20 > Current queue_setup behaves like that: >=20 > queue_setup(queue) > { > if (device is started) > return with error; > if (queue is already setup) > queue_release(queue); >=20 > do_queue_setup(queue); > } >=20 > Preserving current behavior and introducing ability to setup queue for > already started device: >=20 > queue_setup(queue) > { > if (queue is not stopped) > return with error; > if (queue is already setup) > queue_release(queue); >=20 > do_queue_setup(queue); > } >=20 > What is proposed in your patch: >=20 > queue_setup(queue) > { > if (queue is already setup) { > /* via release */ > if (if device is started AND queue is not stopped) > queue_stop(queue); >=20 > queue_release(queue); > } >=20 > do_queue_setup(queue); >=20 > if (device is started AND deferred_start for the queue is off) > queue_start(queue); > } >=20 > That looks quite different from current queue_setup() behavior plus you > introduce extra meaning for rte_eth_rxconf.deferred_start. > All of that in not obvious to the user way. >=20 > I still don't see any good reason to change existing queue_setup() behavi= or in > a such significant way. > So my vote for the proposed new behavior is NACK. >=20 > If you really strongly feel that current queue_setup() functionality has = to be > overloaded (what you propose is really queue_stop_setup_start) - then I > think it should be first stated clearly within RFC and discussed with the > community. > Same for overloading deferred_setup field. OK, I will consider this on a separate RFC patch, I don't think involve aut= o start/stop in the queue_setup context bring any trouble, =20 To me it simplify application's code, just like we don't need an additional= queue_start call after queue_setup / dev_start, since queue could be configure auto started at queue_setup. Regards Qi >=20 > > if application want to re_setup a queue on a running device, of cause i= t > want queue can be stopped first. > > Why we set unnecessary barriers here? > > > > > 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 =3D dev_start + queue_setup > > > > > Queue_setup(deferred) + dev_start + queue_start =3D dev_start + > > > > > queue_setup(deferred) + queue_start. > > > > > Queue_setup + dev_start + queue_setup(same queue) =3D 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 =3D queue_setup + dev_start + > > > > queue_setup(same queue) > > > > > > > > > But not > > > > > Queue_setup + dev_start =3D dev_start+ queue_setup + queue_start > > > > > Queue_setup(deffered) + dev_start +qeueu_start =3D dev_start+ > > > > > queue_setup (ignore deferred)+ queue_start Queue_setup + > > > > > dev_start + queue_setup(same queue) =3D dev_start + queue_setup + > > > > > queue_stop + queue_setup + queue_start. > > > > > > > > Third item should be > > > > Queue_setup + Queue_setup(same queue) + dev_start =3D 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. > > > > I can't agree this, actually it's quite simple to use the APIs. > > User just need to remember, now, it's free to re-order queue_setup and > dev_start, both call sequence reach the same destination. > > And if user does want to control queue start at specific time, just > > use deferred_start_flag and call queue_start explicitly as unusually, > > nothing changes Actually I agree with what Bruce said: > > "keeping existing behavior unless there is a compelling reason to chang= e" > > The patch does try to keep consistent behavior from user's view. >=20 > It doesn't - that's the problem. > Konstantin >=20 > > > > Regards > > Qi > > > > > > > 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 =3D queue_setup(...); if (rc =3D=3D 0) > > > > > > > > > > queue_start(...); > > > > > > > > > > > > > > > > > > application no need to call queue_start explicitly in thi= s case. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We have a pretty well defined API here let's keep it li= ke that. > > > > > > > > > > Konstantin