From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0059.outbound.protection.outlook.com [104.47.32.59]) by dpdk.org (Postfix) with ESMTP id 3815F1B011 for ; Fri, 12 Jan 2018 15:46:42 +0100 (CET) Received: from BN6PR03CA0068.namprd03.prod.outlook.com (10.173.137.30) by CY1PR03MB2361.namprd03.prod.outlook.com (10.166.207.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.7; Fri, 12 Jan 2018 14:46:41 +0000 Received: from BN1BFFO11FD008.protection.gbl (2a01:111:f400:7c10::1:178) by BN6PR03CA0068.outlook.office365.com (2603:10b6:404:4c::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.407.7 via Frontend Transport; Fri, 12 Jan 2018 14:46:41 +0000 Authentication-Results: spf=fail (sender IP is 192.88.168.50) smtp.mailfrom=nxp.com; intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=fail action=none header.from=nxp.com; Received-SPF: Fail (protection.outlook.com: domain of nxp.com does not designate 192.88.168.50 as permitted sender) receiver=protection.outlook.com; client-ip=192.88.168.50; helo=tx30smr01.am.freescale.net; Received: from tx30smr01.am.freescale.net (192.88.168.50) by BN1BFFO11FD008.mail.protection.outlook.com (10.58.144.71) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.20.345.12 via Frontend Transport; Fri, 12 Jan 2018 14:46:41 +0000 Received: from [10.232.14.39] ([10.232.14.39]) by tx30smr01.am.freescale.net (8.14.3/8.14.0) with ESMTP id w0CEkcUw030087; Fri, 12 Jan 2018 07:46:39 -0700 To: "Trahe, Fiona" CC: Hemant Agrawal , "Xu, Rosen" , "dev@dpdk.org" References: <20180102125749.2379-1-shreyansh.jain@nxp.com> <20180102125749.2379-2-shreyansh.jain@nxp.com> <348A99DA5F5B7549AA880327E580B435892EFE92@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B435892F0D40@IRSMSX101.ger.corp.intel.com> From: Shreyansh Jain Message-ID: <4adc1036-6d91-a550-a80a-37347dae184c@nxp.com> Date: Fri, 12 Jan 2018 20:30:54 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <348A99DA5F5B7549AA880327E580B435892F0D40@IRSMSX101.ger.corp.intel.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131602420014254425; (91ab9b29-cfa4-454e-5278-08d120cd25b8); () X-Forefront-Antispam-Report: CIP:192.88.168.50; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(346002)(376002)(39380400002)(396003)(39860400002)(2980300002)(1110001)(1109001)(339900001)(3190300001)(13464003)(24454002)(199004)(189003)(36756003)(81156014)(8676002)(23676004)(2486003)(97736004)(6246003)(6916009)(498600001)(59450400001)(77096006)(53936002)(58126008)(67846002)(305945005)(76176011)(106466001)(81166006)(4326008)(6666003)(31696002)(356003)(105606002)(53546011)(2950100002)(8656006)(64126003)(68736007)(47776003)(50466002)(83506002)(316002)(85426001)(229853002)(104016004)(8936002)(2906002)(5660300001)(65826007)(230700001)(65956001)(65806001)(54906003)(93886005)(31686004)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR03MB2361; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD008; 1:k0nVO47GupFo2pNx+UAhwxYpMNB9QhmqxHWfrhk1sLJJXop+JBhRec+wi/n8cGF9BUYwiRqfkBq9LhGI+Ywhcc9UxvDw3zylWXOKDsunhPZUG06pqToqGQaQyTjmvYua X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 858bac71-37fb-4b6b-0959-08d559cb4aff X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020083)(5600026)(4604075)(2017052603307); SRVR:CY1PR03MB2361; X-Microsoft-Exchange-Diagnostics: 1; CY1PR03MB2361; 3:hT/I2XW0fxXTxxghNJIuz9kx1kX0soiI9NnUd+eRRZBWa5A6Olok/KOfm5VrAw15M0Uwta/LBI6wLbsZFlmhJSm9NgVouLLJp5ST3L1XYfOPF4cBxIU9YiQ2lwbfWWx/hgjAF9jgCBoAh72+bvdVY0/+D3yefqgO+2eax226xNIs0kEvBoIQSvmxJcsRpy8hT8+A8Wvq+ToWAqa021EPpONbrKXL5St7Jfb75XzKRBqsBBQmeg4PpWxbMf91Qp9WOREFGxU1Nczl8XbuyWk5GQcDQeR90z6adDiDQJVK0c/l1a3j1Ib88wSLyICUrCp9+iCVToibhrTR5rja23PiCXTpiAk9YaS0QKvck+xJssI=; 25:blmKNeQh1+BaSGCAKHReZUrw4btp0CxEDsde6ZIvd64cTHM8y4Nc2TWda7+guZwA8Dt2JChCv6HMtJUJLZdswYVbcvR8eSV3yc4UGVC3A+6vD5yExxS/1ss67vW+1tD318P8xuz8A5a5wmUjpraxG0QKN4nPWWK7dgV4dog7n1lpm2uq9XK02zZHNCA0uKEw+HivuJIXb8KA95yKycjqWGcPF/HyY+n3iZhIIVFR/1Pm9NXDa3fLpr7qFwLhTXQRwVlk9LuE+HIuss6g2HOpTPyG57DEgX69bCgSucxbprkIbIW56w5AOld/lG3pUry3sbNt86gNyiXnNU+OaEMofw== X-MS-TrafficTypeDiagnostic: CY1PR03MB2361: X-Microsoft-Exchange-Diagnostics: 1; CY1PR03MB2361; 31:42EJCxd2nuZ9DjT5Nqx9+6gtWX0oyUFrAWseVyNKDy0n0viNoBC8xeJ8iKaEBjGKAC/JxvJOpxNqW6cO3mOS7lLxchZg2jJcWHQDAPzLNHA6JpGZ9e2dA1s8SBN6XKr94fJXG/9LJxGsj99uFB9dkK/LSIik5Fp2SCAaYiEam9jEWR/gXITBlr/UUiZkEZMl1znuuKNGr2M3u8KGj5zXHuYW+upuyFW+wygVKdmCwJg=; 4:aIL1ha+lV6COg5Xfn3GXKEE47MOp3Q74RGGpk23x3oYtsgSnOJd+BcVrqlknNkvASHIyYPu3QPmucxHZNeNzPQR8O5l/DSIIhpiEwUNUmf3YttY8tUnX5A4pc4gdqYsrk9G8hipMBp60g2MaaYOV1Gtkt9+Yg7D7JLMBh6BgSzvXjjS78+s9eUJThikAvsYDTEvzdANxZZoIHCKbSJHyPa5c1zwEMNf+rKXJDgJJBM7NKaRrm5qSVvEjh07g5fWvVraKYGN30YGI9cKOEIo1YwX2ZD3q264+r5ppPbD0LhdKdqqB6eTiRMffgDzWNQvrK+2kdMTPhC+dd2bIDvF6S+kVgSIlePbSI2cbDS9hL1UOpEv1qKTzk5Dou52ocG80 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(185117386973197)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6095135)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231023)(944501144)(93006095)(93001095)(6055026)(6096035)(20161123565025)(20161123561025)(20161123559100)(201703131430075)(201703131433075)(201703131448075)(201703151042153)(20161123556025)(20161123563025)(201708071742011); SRVR:CY1PR03MB2361; BCL:0; PCL:0; RULEID:(100000803101)(100110400095)(400006); SRVR:CY1PR03MB2361; X-Forefront-PRVS: 0550778858 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjAzTUIyMzYxOzIzOk1nbHdrTHlVTzZ4TDJ5WUFZUTJ4c3Z2bEdw?= =?utf-8?B?akdIQnhXT20yVWJDQWxKWEhXOFpRejB4ZDdMcVdlNVU1a3NGZTVUQkpqUjMv?= =?utf-8?B?WlBEYkxyaVV0NEhIK1NoWHFDUW9ZZ2lNeVpnc2J3Si9qUlQrb2FOeHBldW85?= =?utf-8?B?NjMwN01DcUtUb0luM0VZYTFzQ3FTWDdqSy9XWVVQbUpiWmNFWEtwNE1uOWZW?= =?utf-8?B?cERaQ3hyVlVMa3dEd0R2eU5YT0Z6ZHpZOXJIRXRUOE5DaU9VN0kvbEpMc0tv?= =?utf-8?B?RjJlVFc1dE11NU1uMGNGNUxmT01zS01NcTRYSmZUdWJybDN0dzVEMytnNWJw?= =?utf-8?B?enhVbFBQTDFDZ3ZHUXczaHhjNmdhU3A4RmU5K3ZEUnR3T01VVkg3ODJKT0Nw?= =?utf-8?B?L1RsZlNYeFJSTy9GTUxpQ2tEbTE3QnZwM21hOXpPb1l4RitjUkF0VkQ5UG4v?= =?utf-8?B?dE9FT0Z0cUZiRSs3cTJhU3JuVnlVTHdITURmejExSWc4R0UxZFRBVlZNWERF?= =?utf-8?B?VkpqU0wyMDJKZkM5dGp2ZTZMOVA4ejJJZThZWU1CWWFueXp6MUdwdzl0OEVh?= =?utf-8?B?bHEzSzRIL3BZQVFZblJCRVlCU3dCMXJ4M3QzRCtVVGFEVmRQRlRCQVdTMFZW?= =?utf-8?B?Q09DWlVyazdjczMzWWJPMjNhUUFRd21UTkw2R0IwUXpwbXN5bGNHUWtzK0Yw?= =?utf-8?B?L2doRkdUMWsrbFlNSWhjb3pzWVJPY3k1U0JaTS8rTENtMFdiS3hDYlRtS3RD?= =?utf-8?B?M3hKRlNSSHRseXZ6NkhvWjFNaElPTjNOZHVMTXh6cHl5Qkg2d0w2b3F5VGpJ?= =?utf-8?B?TFdsbHpKUnVkclRNdC9aVXpYdTVZUUdGeHlaZDEwd0g4akpRc0llSWg1dlBh?= =?utf-8?B?ZHByaDF4REwyWFk3azlQZmVsU0lHMEptNVF3ZjdPTWk5VWxqbG9rZUN6R3ZX?= =?utf-8?B?b1JKTVlHR3A3SHJSOTAyVEx4NzlmREpKWDdaQTZRemIvMzE0VXp6N0RmNVh1?= =?utf-8?B?Y3BNMEJHVSt4TXFrYXBZOC95cG5RdzJzc0wrMnlsYkRjeThHdnU3MS9hVVJl?= =?utf-8?B?R2VMaENDU0dkQ2lLd0hrSEtNY1BLSDI1ZVNLNnFNUVdNOWJXNWlaVVZuRnR6?= =?utf-8?B?S0lNZ29QVnRNU1l0ak1sTXMxUDRyK29mT2o2M2ZtRU9yeGFwR3JRMENqazYy?= =?utf-8?B?SEFkRmZ0WWJETStDRW9jdlQ5QlJjU0d3Y0d1SXdZRUExN2wzb0FPSllmMk15?= =?utf-8?B?dU8zbzQ5ZFB2V2R2THhodGRwZ3Vub1JLOWZneTVRZVpRM0JVbzA0KzFLb3BI?= =?utf-8?B?UEN1cEJvRjRVa09rNVk0azBhY0Z6SkxUTDF0dzlsa3NJUXpYREdrS2NoT3Vv?= =?utf-8?B?T3dFWmUwOTRRd1dselE5cWRSWVhYUHQyNFdEL09UNTNoZUdybHprMkxaS1dQ?= =?utf-8?B?SnNtZlBsemltOTUvcU94SXg0KzhRK2UzS3VxOHhYR0xkcDIzbkUvanA0V01i?= =?utf-8?B?YVUzT1ZzWGxFN002RkJSSlFkOW1zTEhwR1V3UTc3NDlUaDFONEd2OWZiVWZr?= =?utf-8?B?OFdNTXNtblNXQklkTTVsTkxSTmNWOHJ2eVdRUG1aUmN4MWRVT3QvbloyaytN?= =?utf-8?B?bHVvZnA2ZEpiZ1E2YWJDNWJlVHE5Sm5FSGQzWXIzdkVSNjZEeEMrOWlGVEtF?= =?utf-8?B?ZWV5YmJVOUZsKzBySUtLRXJ0elZmeTR4SGl2bGxwOHphbGhHRlgvbzEveTRB?= =?utf-8?B?NDRZU0ZJTVptN2wwdzc5ZDN3MVkrVHB6L2FqdjJ3dkhWT1lGS2xMb2VDdnhj?= =?utf-8?B?a1FabkNLOFFFblJmcXZrZ0d4Skh1OXk4Q2VUQkNjQXo3SUd5amQ2NmQ5TkV3?= =?utf-8?Q?iYXSiYwBlaJJP+ya+Em7OfAC6kUMnemK?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR03MB2361; 6:3T563iXZEEUTRfK2UZphHBh51xqXUpesufwW7fxOaurKi0iPV9NuOc+t71dRdGf9wEpqqddQXi9NNbsSJMaoeTwm+WEhfErddwY1zc7K2ZnkCXx8hrvD5LaPECVW02iw61VqmZZ2yZbu2XN0tfjjNxcEJeKUUIPKVjNiooiSwjq/ZUIPxakBPxLTI0pj1eDEo5AqSOa5rfrGy7nsOGNPFNzc/oKDFNsBU2yPPD+jc+oa8+K00EupNRG8XJSShmqlgPKat20u0jnL9gZ0oayECbfdoRZzAH7UmPUUFyxEMu8WOfnvRcW97uz96EwqB/g/+KRJAITbeR53s7Z64J2zY0pl05MHIMiP4Z8/EinWE/k=; 5:UMHOle6jU4XQvB9KGA+pWMONlplDxk960j9YPJFwDnQRrk0lZlqHYSRWCu61UT9DywzdHB5FryCs2Afnvn7vH2xjt2hdpvrWiJa/ZlahqsXxrwUKgW2t4IZfzB+Ehr72Om0lQeTS3GIbFmPErhjmU9l4e/blEpzDwiX1WnUToTY=; 24:88KEc0bdpcnAM0ImM8yWN7VImSZaJ5w57vtIj9WpS9IgRjqPHtCFVgk/0mZ/IUCQHggqdf6KJqwPNJtsJ6YHt/He8syN+2eKRQ2DCJSTbXc=; 7:rvglmoW3YM3LMX6if89mu3kYHD1TzkgOJHmzLeuv6sE+9dD0aWOpvTtK9W7T9y5yVsphool2w2fLDC23wmsmqelAHzfjGYm+pJtVRuyLLY5t1x2uwBwkYJDP6Vfu8kFCC0u5ra6kaMoI+3O3MeSZaAJ6ulbpZTLNBWzCRYBv7VI9+pYiLYFGFV7kuGJyhOX8Z6GXzPohS0MiKlXi5Zg/3t8lGAfTu2hB2+g4Y/QcYA6e+XkVABKcKqy2oNWBXjCK SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2018 14:46:41.2070 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 858bac71-37fb-4b6b-0959-08d559cb4aff X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[192.88.168.50]; Helo=[tx30smr01.am.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2361 Subject: Re: [dpdk-dev] [PATCH v1 1/5] rawdev: introduce raw device library support 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: Fri, 12 Jan 2018 14:46:43 -0000 Hello Fiona, Apologies for delay in my response. Some comments inline... On Monday 08 January 2018 08:21 PM, Trahe, Fiona wrote: > > >> -----Original Message----- >> From: Shreyansh Jain [mailto:shreyansh.jain@nxp.com] >> Sent: Monday, January 8, 2018 2:10 PM >> To: Trahe, Fiona >> Cc: Hemant Agrawal ; Xu, Rosen ; dev@dpdk.org >> Subject: Re: [PATCH v1 1/5] rawdev: introduce raw device library support >> >> Hello Fiona, >> >> On Saturday 06 January 2018 07:10 PM, Trahe, Fiona wrote: >>> Hi Shreyansh, >>> >>> This looks like a useful generic device, thanks. Some comments below. >> >> Thanks for taking interest and sending your review. >> I have some responses inline.... >> (And I have shortened the original email) >> >> [...] >> >>>> +#include "rte_rawdev.h" >>>> +#include "rte_rawdev_pmd.h" >>>> + >>>> +/* dynamic log identifier */ >>>> +int librawdev_logtype; >>>> + >>>> +/* Maximum rawdevices supported by system. >>>> + */ >>>> +#define RTE_MAX_RAWDEVPORTS 10 >>> [Fiona] Typo in comment above? There's RTE_RAWDEV_MAX_DEVS, RTE_MAX_RAWDEVS and >> RTE_MAX_RAWDEVPORTS. Are all 3 necessary and what's the relationship between ports and devs? >> >> This is a stupid mistake by me. It should be only RTE_RAWDEV_MAX_DEVS. >> RTE_MAX_RAWDEVS is useless and I will remove RTE_MAX_RAWDEVPORTS. >> They are intend the same thing - number of max devices supported. >> >>> >> >> [...] >> >>>> + >>>> +/** >>>> + * Allocate and set up a raw queue for a raw device. >>>> + * >>>> + * @param dev_id >>>> + * The identifier of the device. >>>> + * @param queue_id >>>> + * The index of the raw queue to setup. The value must be in the range >>>> + * [0, nb_raw_queues - 1] previously supplied to rte_rawdev_configure(). >>>> + * >>>> + * @see rte_rawdev_queue_conf_get() >>>> + * >>>> + * @return >>>> + * - 0: Success, raw queue correctly set up. >>>> + * - <0: raw queue configuration failed >>>> + */ >>> [Fiona] cut and paste error above - should be release. >> >> Indeed. Thanks for pointing out. >> I will fix this. >> >>> >>>> +int >>>> +rte_rawdev_queue_release(uint16_t dev_id, uint16_t queue_id); >>>> +/** >>>> + * Get the number of raw queues on a specific raw device >>>> + * >>>> + * @param dev_id >>>> + * Raw device identifier. >>>> + * @return >>>> + * - The number of configured raw queues >>>> + */ >>>> +uint16_t >> >> [...] >> >>>> + >>>> +/** >>>> + * Allocates a new rawdev slot for an raw device and returns the pointer >>>> + * to that slot for the driver to use. >>>> + * >>>> + * @param name >>>> + * Unique identifier name for each device >>>> + * @dev_priv_size >>>> + * Private data allocated within rte_rawdev object. >>>> + * @param socket_id >>>> + * Socket to allocate resources on. >>>> + * @return >>>> + * - Slot in the rte_dev_devices array for a new device; >>>> + */ >>>> +struct rte_rawdev * >>>> +rte_rawdev_pmd_allocate(const char *name, size_t dev_private_size, >>>> + int socket_id); >>> [Fiona] The driver must allocate a unique name for each device, and the application presumably must >> search through all devices using dev_count and dev_info_get for each >>> until it finds a name it expects? But will the application always know the name chosen by the PMD? e.g. >> driver type xyz might find 10 devices and call them xyz_0, xyz_1, xyz_2, etc >>> The application wants to look for any or all xyz devices so must know the naming format used by the >> PMD. >>> Would it be useful to have 2 parts to the name, a type and an instance, to facilitate finding all devices of >> a specific type? >> >> let me state what I have understood: >> >> There are two types of devices: >> 1. which are scanned through a bus (PCI ...) >> 2. which are created through vdev (devargs, vdev_init) >> >> for those which are scanned through a bus, it is easy to append a >> "type_" string during device naming. >> for those which are added through command line, this pattern would have >> to be choosen by the application/user. >> >> further, a rawdevice doesn't have a specific type. So, type would be >> purely be defined by the driver (scan) or the device name itself >> (vdev_init). >> >> So, eventually the "type_" field would be left out for driver or >> application to decide. framework (lib/librte_rawdev) would never >> override/append to it. >> >> Is this understanding correct? > [Fiona] Yes. I'm probably overcomplicating it. > I was considering scanned devices and e.g. a case where 2 PMDs inadvertently pick the same name. > One idea would be each driver would register a type string with the lib layer and > all its device names must start with this, thus ensuring that each device name is unique. > With the vdev devices the application can ensure device names are unique. > A driver would not be allowed to use a name starting with a string which another PMD had already registered. > > This would allow looser coupling between the applications and the PMDs, as applications > would not need to know the exact name format of device name, just know the type it wants to use > and search for all devices with names starting with that string. > But I'm probably anticipating issues which wouldn't happen in real world applications. > i.e. though there may be many PMDs and applications in the dpdk codebase using this lib in future, > it's likely only a small number will be compiled into any build so such name clashes are unlikely to occur. > And the applications must be tightly coupled with the PMD anyway to make use of the device, so > that's probably not a concern either. I agree with the last line that applications have to be tightly coupled with PMD in this case. That defines (or prevents defining) a lot of semantics. While creating the patches, even I was thinking of standardizing the naming (taking hint from some of Gaetan's work on devargs) but I couldn't think of a policy which can be enforced only by the rawlib. I concur with you that conflicting naming in a real world scenario is theoretically possible, irrespective of how rare it might be. I suggest that we continue as is and expand this in future when we have more clarity or even some real-world application samples. You have any objections to this? > >> >> I will send a v2 shortly with your comments. I will also try and think >> through your suggestion about name containing "type_" - I do think it is >> useful but not really sure how would it define semantics between driver >> and application. >> >> - >> Shreyansh