From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 0583B37A2 for ; Mon, 13 Aug 2018 10:38:54 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1-us3.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id A076D6C006B; Mon, 13 Aug 2018 08:38:53 +0000 (UTC) Received: from [192.168.1.16] (85.187.13.33) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 13 Aug 2018 09:38:47 +0100 To: "Lu, Wenzhuo" , Thomas Monjalon , "Yigit, Ferruh" CC: "dev@dpdk.org" References: <1531373220-42150-1-git-send-email-wenzhuo.lu@intel.com> <6A0DE07E22DDAD4C9103DF62FEBC09093B804CD6@shsmsx102.ccr.corp.intel.com> <6A0DE07E22DDAD4C9103DF62FEBC09093B804D6C@shsmsx102.ccr.corp.intel.com> <1716659.kXphz3AMnz@xps> <6A0DE07E22DDAD4C9103DF62FEBC09093B81A090@shsmsx102.ccr.corp.intel.com> From: Andrew Rybchenko Message-ID: <98adeea9-f334-b0a7-599d-c73a11927ddf@solarflare.com> Date: Mon, 13 Aug 2018 11:38:41 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09093B81A090@shsmsx102.ccr.corp.intel.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [85.187.13.33] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24028.003 X-TM-AS-Result: No-18.301800-8.000000-10 X-TMASE-MatchedRID: dL10VBB8yocOwH4pD14DsPHkpkyUphL9Ud7Bjfo+5jRGrRj9faLVBBRH GnUfHCcG5qduK012SP7ih/b1HlnM9aN0uxYINvQ12os3ueKAsFT4h+uI7dxXxE5j0OsMj9E6Tba f0ad0nbbYHOC/v3JS19U1netJunBfUlzBXm/6ZUVmVHNo7XGknV7OZ6hrwwnzc8FZmOUzKzbmxl PBgd8EzuysRepJ78jJUVdAWv33ZDzK4Jk0iIjDZ6OuVibdZNTvLAnNohUyMa3ceXQ6q2ggSsAfI MzUPnhOjRMwRxWMc3DAX32r0ss3R4UJf3YQjB6CWZbr7hxHnYRUENBIMyKD0doAm89jnq3+166X b3/Hw4O7KT8e5NWWCj+Lkb7uTiTjiqppOxi9o1aQgDXBbWe8E9tb21l1J0jcaKyfWaPPzZ9LyiF Ck+j72fbYZPZ20YJlqS2Ud07XxYVb8Ol7R+ysiriMC5wdwKqdkos2tunL8DRaW2Ktn+I8/rDWHF ry+EP48NbsmAnr7hPQN6BjbBAivm18DcO3+y6JjtK7dC6UBnm5pw2tsxj4tGY9MlIVazKro8WMk QWv6iVvViiMFIoRrKebHCxzBV4T3QfwsVk0UbtuRXh7bFKB7pwMViA+nyAVT6jEZ3JbyQV5NNqY VlHNQ2l8rjnVXhPyYDttQUGqHZU= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--18.301800-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24028.003 X-MDID: 1534149534-oadHeTVMK4tk 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: Mon, 13 Aug 2018 08:38:55 -0000 On 13.08.2018 05:50, Lu, Wenzhuo wrote: > Hi Thomas, > > >> -----Original Message----- >> From: Thomas Monjalon [mailto:thomas@monjalon.net] >> Sent: Wednesday, August 1, 2018 11:37 PM >> To: Lu, Wenzhuo ; Andrew Rybchenko >> ; Yigit, Ferruh >> 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-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 >>>> >>>> Hi Andrew, >>>> >>>>> -----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 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; > } May be it is just very bad example, but as I understand nb_rx_queues is mainly required to configure the device properly. Or should app configure, get new value, reconfigure again, get new value and so on and stop when previous is equal to the new one. Yes, I dramatise and it sounds really bad. In any case it would over-complicate interface and no single app will do it correctly. Stable dev_info is simple. If there are real cases when something can't be stable (and may be recommended Rx/Tx ring sizes is good example, it should at least documented in dev_info structure description or may be moved to separate API. > 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. >