Hi Thomas,
> -----Original Message----- > From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Wednesday, August 1, 2018 11:37 PM > To: Lu, Wenzhuo <wenzhuo...@intel.com>; Andrew Rybchenko > <arybche...@solarflare.com>; Yigit, Ferruh <ferruh.yi...@intel.com> > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2] ethdev: fix device info getting > > 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?). Sorry, I missed this mail. I have the concern that different NICs have different behavior. One info can be stable on a NIC but dynamic on another. Considering this, we may better not splitting the rte_eth_dev_info_get to 2 APIs. And comparing with handling this in rte layer, maybe we can let every NIC has its own decision. I have an idea. Maybe we can add a parameter for potential dynamic fields. Like, Changing uint16_t nb_rx_queues; to struct nb_rx_queues { uint16_t value; bool stable; } By default, the stable is false. Then every NIC can maintain its own behavior. Some fileds that must be stable can be left unchanged, like, driver_name, max_rx_queues. As this patch is just reversing a bad commit to fix a bug, if my idea sounds good or worth discussing, I can send another RFC mail for it.
