16/07/2018 03:58, Lu, Wenzhuo: > Hi Andrew, > > > -----Original Message----- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Lu, Wenzhuo > > Sent: Monday, July 16, 2018 9:08 AM > > To: Andrew Rybchenko <arybche...@solarflare.com>; dev@dpdk.org > > Cc: Yigit, Ferruh <ferruh.yi...@intel.com>; Thomas Monjalon > > <tho...@monjalon.net> > > Subject: Re: [dpdk-dev] [PATCH v2] ethdev: fix device info getting > > > > Hi Andrew, > > > > > -----Original Message----- > > > From: Andrew Rybchenko [mailto:arybche...@solarflare.com] > > > Sent: Friday, July 13, 2018 4:03 PM > > > To: Lu, Wenzhuo <wenzhuo...@intel.com>; dev@dpdk.org > > > Cc: Yigit, Ferruh <ferruh.yi...@intel.com>; Thomas Monjalon > > > <tho...@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 one. > > > 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 > > similar > > suggestion like this. But we don’t make it happen. > > The reason is, you see, this is the rte layer's behavior. So the user > > doesn'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 before > > getting the info or not. > > So, to my opinion, we can still keep the behavior. We only need to split 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 comments > is about how to use the APIs, > rte_eth_dev_info_get, rte_eth_dev_configure. To my opinion, > rte_eth_dev_info_get is just to get the info. It can be called anywhere, > before configuration or after. It's reasonable the info changes with the > configuration changing. > 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 > configuration. > > A question, maybe a little divergent thinking, that APP should have some > intelligence to handle the capability automatically. So getting the > capability is not so good and effective, looks like we still need the human > involvement. Maybe that the reason currently we suppose APP know the > capability from 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?).
