From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v2] ethdev: fix device info getting Date: Wed, 01 Aug 2018 17:36:30 +0200 Message-ID: <1716659.kXphz3AMnz@xps> 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-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org To: "Lu, Wenzhuo" , Andrew Rybchenko , "Yigit, Ferruh" 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) In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09093B804D6C@shsmsx102.ccr.corp.intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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?).