From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas@monjalon.net>
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
 [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 3891A8E60
 for <dev@dpdk.org>; Wed,  1 Aug 2018 17:36:37 +0200 (CEST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
 by mailout.nyi.internal (Postfix) with ESMTP id 93764215AC;
 Wed,  1 Aug 2018 11:36:36 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute1.internal (MEProxy); Wed, 01 Aug 2018 11:36:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
 cc:content-transfer-encoding:content-type:date:from:in-reply-to
 :message-id:mime-version:references:subject:to:x-me-sender
 :x-me-sender:x-sasl-enc; s=mesmtp; bh=RDDHaPYHIVq7u/NWY2nOuLuPJ3
 +daaZUlPaOA4A9eNw=; b=W6UA5D84yrpEHkNAxcU0HD1kHhARtFh5tiviwU7Aif
 lWgGichq3dmZr+Qx0R07o1S3v8XERKzrZKSMskNvjAhxE9qoPqVS6sUYIGHIRiDr
 qzGFnqKqaU6feacDptlwZa6k1jBWO17qKYfo8W5fe4sspCoYgv+YtDgXobgYdbK4
 Q=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-transfer-encoding:content-type
 :date:from:in-reply-to:message-id:mime-version:references
 :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=RDDHaP
 YHIVq7u/NWY2nOuLuPJ3+daaZUlPaOA4A9eNw=; b=ntuzp3rweTrt24iD7Q9u/P
 Uw0vg8PQXAYAZc0aisMRxLbEcfj0JGLHy5lfnhFXu5Y4AXqYK9bKYCrrPNQc5riH
 /bgPagAf0pbBpXgpuBud0XxUY54SX15hvTPsDSX9xcxrlsQGqp6MsZRNj7IbC56D
 g+CHe6433mPxxY7fFba7XTKnHV9GH9c5S38mC6EoAuKU+6VZDW+OX8XFhhL5773k
 ddCM9/5fMpLlRtinSuBchDdgkc60pj+ImtEdInE4bcqgySV3kr9wYund+kurXCcg
 3SE/wd8FNX2kVAmUwGTFCkSaEj35Uhd23s9TM4rWkaXhWNhSt0XrqT1d6gGWOEHg
 ==
X-ME-Proxy: <xmx:hNNhW-GPewgRwcOmavkeo2pPKSF9lAxfEuCItyxNQv2311sIKS7J_g>
 <xmx:hNNhW4JcDNGoK-kCmLuwTUf6dEUS5QabapkH88LnJqnaJrZdR_bJww>
 <xmx:hNNhW2iJqQ4hAKzp1QF_NjCUNcBavqkP_mexqbzInwOSAeAGBgK7sw>
 <xmx:hNNhW3xN1O9JBS__TC9tsjIWzZ46yUC3MXFaByBCXkCA_YTvTX7q9A>
 <xmx:hNNhW_4zyPDnOVmAGplFpfRumc7rLV8EOGEgSDgOtUUgV6gcLtW_Xw>
 <xmx:hNNhWz_pJ-Kc6OUlO5rD8xboKZXCVXUjbLDm_VJZj4D0j_MYc0iBzw>
X-ME-Sender: <xms:hNNhW0Ms2mSbJMQTliXt3jDRwh7jtjx2SGZu-PjBSXJwaKzmPbr43Q>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
 by mail.messagingengine.com (Postfix) with ESMTPA id 75F4E1025C;
 Wed,  1 Aug 2018 11:36:35 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
 Andrew Rybchenko <arybchenko@solarflare.com>, "Yigit,
 Ferruh" <ferruh.yigit@intel.com>
Cc: dev@dpdk.org
Date: Wed, 01 Aug 2018 17:36:30 +0200
Message-ID: <1716659.kXphz3AMnz@xps>
In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09093B804D6C@shsmsx102.ccr.corp.intel.com>
References: <1531373220-42150-1-git-send-email-wenzhuo.lu@intel.com>
 <6A0DE07E22DDAD4C9103DF62FEBC09093B804CD6@shsmsx102.ccr.corp.intel.com>
 <6A0DE07E22DDAD4C9103DF62FEBC09093B804D6C@shsmsx102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [dpdk-dev] [PATCH v2] ethdev: fix device info getting
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://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Aug 2018 15:36:37 -0000

16/07/2018 03:58, Lu, Wenzhuo:
> Hi Andrew,
>=20
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Lu, Wenzhuo
> > Sent: Monday, July 16, 2018 9:08 AM
> > To: Andrew Rybchenko <arybchenko@solarflare.com>; dev@dpdk.org
> > Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon
> > <thomas@monjalon.net>
> > Subject: Re: [dpdk-dev] [PATCH v2] ethdev: fix device info getting
> >=20
> > Hi Andrew,
> >=20
> > > -----Original Message-----
> > > From: Andrew Rybchenko [mailto:arybchenko@solarflare.com]
> > > Sent: Friday, July 13, 2018 4:03 PM
> > > To: Lu, Wenzhuo <wenzhuo.lu@intel.com>; dev@dpdk.org
> > > Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon
> > > <thomas@monjalon.net>
> > > Subject: Re: [dpdk-dev] [PATCH v2] ethdev: fix device info getting
> > >
> > > Hi, Wenzhuo,
> > >
> > > I'm sorry, but I have more even harder questions than the previous on=
e.
> > > This questions are rather generic and mainly to ethdev maintainers.
> > >
> > > On 13.07.2018 05:42, Wenzhuo Lu wrote:
> > > > The device information cannot be gotten correctly before the
> > > > configuration is set. Because on some NICs the information has
> > > > dependence on the configuration.
> > >
> > > Thinking about it I have the following question. Is it valid behaviour
> > > of the dev_info if it changes after configuration?
> > > I always thought that the primary goal of the dev_info is to provide
> > > information to app about device capabilities to allow app configure
> > > device and queues correctly. Now we see the case when dev_info changes
> > > on configure. May be it is acceptable, but it is really suspicious. If
> > > we accept it, it should be documented.
> > > May be dev_info should be split into parts: part which is persistent
> > > and part which may depend on device configuration.
> > As I remember, the similar discussion has happened :) I've raised the s=
imilar
> > suggestion like this. But we don=E2=80=99t make it happen.
> > The reason is, you see, this is the rte layer's behavior. So the user d=
oesn't
> > have to know it. From APP's PoV, it inputs the configuration, it calls =
this API
> > "rte_eth_dev_configure". It doesn't know  the configuration is copied b=
efore
> > getting the info or not.
> > So, to my opinion, we can still keep the behavior. We only need to spli=
t it
> > into parts when we do see the case that cannot make it.
> Maybe I talked too much about the patch. Think about it again. Your comme=
nts is about how to use the APIs,
> rte_eth_dev_info_get, rte_eth_dev_configure. To my opinion, rte_eth_dev_i=
nfo_get is just to get the info. It can be called anywhere, before configur=
ation or after. It's reasonable the info changes with the configuration cha=
nging.
> But we do have something missing, like, rte_eth_dev_capability_get which =
should be stable. APP can use this API to get the necessary info before con=
figuration.
>=20
> A question, maybe a little divergent thinking, that APP should have some =
intelligence to handle the capability automatically. So getting the capabil=
ity is not so good and effective, looks like we still need the human involv=
ement. Maybe that the reason currently we suppose APP know the capability f=
rom the paper copies, examples...

I am not sure to understand all the sentences.
But I agree that we should take a decision about the stability
of these infos.
Either infos cannot change after probing,
or we must document that the app must request infos regularly (when?).