From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <konstantin.ananyev@intel.com>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
 by dpdk.org (Postfix) with ESMTP id 4C7C74C76
 for <dev@dpdk.org>; Tue, 20 Mar 2018 14:18:52 +0100 (CET)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga007.fm.intel.com ([10.253.24.52])
 by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 20 Mar 2018 06:18:50 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.48,335,1517904000"; d="scan'208";a="25508918"
Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155])
 by fmsmga007.fm.intel.com with ESMTP; 20 Mar 2018 06:18:49 -0700
Received: from irsmsx105.ger.corp.intel.com ([169.254.7.216]) by
 IRSMSX102.ger.corp.intel.com ([169.254.2.164]) with mapi id 14.03.0319.002;
 Tue, 20 Mar 2018 13:18:48 +0000
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Zhang, Qi Z" <qi.z.zhang@intel.com>
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>
Thread-Topic: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue setup
Thread-Index: AQHTsdzniCAjXGTwQUq3PD1jD08qQaPPOCyAgAF7dxCAACPogIAAkFrA//+RIACAASKVMIAAE/2AgAC3wZCAABZaYIAAQv2QgAJ4pwCAA2up4A==
Date: Tue, 20 Mar 2018 13:18:47 +0000
Message-ID: <2601191342CEEE43887BDE71AB977258A0AB217E@irsmsx105.ger.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>
In-Reply-To: <039ED4275CED7440929022BC67E706115316EDD8@SHSMSX103.ccr.corp.intel.com>
Accept-Language: en-IE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMTMwZWI1YTEtMjYzZC00M2EwLWFkZjMtMjdiN2JhNjU0ZGYxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6Ikg2ZlVtaVdpNlIwdnUydE1GM0pFV2x2MFZTVDQwdUF1K0Exbm9ES0xjbW89In0=
x-ctpclassification: CTP_NT
dlp-product: dlpe-windows
dlp-version: 11.0.0.116
dlp-reaction: no-action
x-originating-ip: [163.33.239.180]
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 <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Mar 2018 13:18:54 -0000



> > > > > > > > > > > >
> > > > > > > > > > > > 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 =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.ty=
pe
> > =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 n=
ow.
> > > > > > > > > > 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 t=
his.
> > > > > > > > > >
> > > > > > > > > > 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 behavio=
r
> > > > > 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 deferre=
d
> > > > 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_sta=
rt().
>=20
> > 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 imply =
something.
>=20
> 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 reconfigure =
without release if first?

If you think queue_release() should be a public API - submit and RFC for th=
at, then we can discuss it.

>=20
> I thinks it's the same pattern for why we have queue_stop / queue_start h=
ere.

Not really from my perspective.
setup/release - to setup/teardown internal queue structures.
start/stop - to start/stop RX/TX on that queues.

> if application want to setup a queue on a running device, of cause it wan=
t queue be started immediately

Some apps might, some might not.
Those who want to start the queue will call queue_start() - simple and stra=
ightforward.

> (if not? It can use deferred_start)

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()=
. */

Now you are trying to overload it with extra meaning:
Do not start queue with rte_eth_dev_start()
if device is already started don't start the queue from the queue_setup().

Looks very confusing to me, plus what is probably worse there is now no con=
sistent 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 or =
at least be as close as
possible to it.

Current queue_setup behaves like that:=20

queue_setup(queue)
{
   if (device is started)
       return with error;=20
    if (queue is already setup)
         queue_release(queue);

   do_queue_setup(queue);
}

Preserving current behavior and introducing ability to setup queue for
already started device:

queue_setup(queue)
{
   if (queue is not stopped)
       return with error;=20
    if (queue is already setup)
         queue_release(queue);

   do_queue_setup(queue);
}

What is proposed in your patch:

queue_setup(queue)
{
     if (queue is already setup) {
         /* via release */
         if (if device is started AND queue is not stopped)
            queue_stop(queue);

         queue_release(queue);
     }

   do_queue_setup(queue);

   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.

I still don't see any good reason to change existing queue_setup()
behavior in a such significant way.
So my vote for the proposed new behavior is NACK.

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 shoul=
d be first stated clearly
within RFC and discussed with the community.=20
Same for overloading deferred_setup field.  =20

> if application want to re_setup a queue on a running device, of cause it =
want queue can be stopped first.
> Why we set unnecessary barriers here?
>=20
> > 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.
>=20
> 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 de=
v_start, both call sequence reach the same destination.
> And if user does want to control queue start at specific time, just use d=
eferred_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 change"
> The patch does try to keep consistent behavior from user's view.

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 f=
or.
> > 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 doe=
s
> > > > 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 immediatel=
y
> > > > > > > > > he can always
> > > > > > > do:
> > > > > > > > >
> > > > > > > > > rc =3D queue_setup(...);
> > > > > > > > > if (rc =3D=3D 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