From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 3891A8E60 for ; 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: X-ME-Sender: 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 To: "Lu, Wenzhuo" , Andrew Rybchenko , "Yigit, Ferruh" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; dev@dpdk.org > > Cc: Yigit, Ferruh ; Thomas Monjalon > > > > 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 ; dev@dpdk.org > > > Cc: Yigit, Ferruh ; Thomas Monjalon > > > > > > 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?).