From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matan Barak Subject: Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller Date: Wed, 14 Sep 2016 11:14:03 +0300 Message-ID: <13a00119-e629-2d34-d08b-c02bb6beceea@mellanox.com> References: <20160901084406.GA4115@lst.de> <20160910161442.GC29259@lst.de> <20160910170151.GA5230@obsidianresearch.com> <20160911133421.GA23384@lst.de> <20160911143522.GL6415@leon.nu> <20160911171409.GA13442@obsidianresearch.com> <20160911172445.GA25953@lst.de> <20160911175235.GB13442@obsidianresearch.com> <20160912050717.GE8812@leon.nu> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-doc-owner@vger.kernel.org To: Parav Pandit , Leon Romanovsky Cc: Jason Gunthorpe , Christoph Hellwig , Tejun Heo , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, Linux Kernel Mailing List , linux-rdma@vger.kernel.org, Li Zefan , Johannes Weiner , Doug Ledford , Liran Liss , "Hefty, Sean" , Haggai Eran , Jonathan Corbet , james.l.morris@oracle.com, serge@hallyn.com, Or Gerlitz , Andrew Morton , linux-security-module@vger.kernel.org List-Id: linux-rdma@vger.kernel.org On 14/09/2016 10:06, Parav Pandit wrote: > Hi Dennis, > > Do you know how would HFI1 driver would work along with rdma cgroup? > > Hi Matan, Leon, Jason, > Apart from HFI1, is there any other concern? I just wonder how things like RSS will work. For example, a RSS QP doesn't really have a queue (if I recall, it's connected to work queues via an indirection table). So, when a user creates such a QP, do you want to account it as a regular QP? How are work queues accounted? > Or Patch is good to go? > > 4.8 dates are close by (2 weeks) and there are two git trees involved > (that might cause merge error to Linus) so if there are no issues, I > would like to make request to Doug to consider it for 4.8 early on. > > Parav > > On Mon, Sep 12, 2016 at 10:37 AM, Leon Romanovsky wrote: >> On Sun, Sep 11, 2016 at 11:52:35AM -0600, Jason Gunthorpe wrote: >>> On Sun, Sep 11, 2016 at 07:24:45PM +0200, Christoph Hellwig wrote: >>>>>>> I've posted some initial work toward a) a while ago, and once we >>>>> >>>>> Did it get merged? Do you have a pointer? >>>> >>>> http://www.spinics.net/lists/linux-rdma/msg31958.html >>> >>> Right, I remember that. Certainly the right direction >>> >>>>> However, everything under verbs is not straightforward. The files in >>>>> userspace are not copies... >>>>> >>>>> user: >>>>> >>>>> struct ibv_query_device { >>>>> __u32 command; >>>>> __u16 in_words; >>>>> __u16 out_words; >>>>> __u64 response; >>>>> __u64 driver_data[0]; >>>>> }; >>>>> >>>>> kernel: >>>>> >>>>> struct ib_uverbs_query_device { >>>>> __u64 response; >>>>> __u64 driver_data[0]; >>>>> }; >>>> >>>> We'll obviously need different strutures for the libibvers API >>>> and the kernel interface in this case, and we'll need to figure out >>>> how to properly translate them. I think a cast, plus compile time >>>> type checking ala BUILD_BUG_ON is the way to go. >>> >>> I'm not sure I follow, which would I cast? >>> >>> BUILD_BUG_ON(sizeof(ibv_query_device) == sizeof(ib_uverbs_cmd_hdr) + >>> sizeof(ib_uverbs_query_device)) >>> >>> ? >>> >>>>> I'm thinking the best way forward might be to use a script and >>>>> transform userspace into: >>>>> >>>>> struct ibv_query_device { >>>>> struct ib_uverbs_cmd_hdr hdr; >>>>> struct ib_uverbs_query_device cmd; >>>>> }; >>>> >>>> That would break the users of the interface. >>> >>> Sorry, I mean doing this inside rdma-plumbing. Since the change is ABI >>> identical the modified libibverbs would still be binary compatible >>> with all providers but not source compatible. Since all kernel >>> supported providers are in rdma-plumbing we can add the '.cmd.' at the >>> same time. >>> >>> The kernel uapi header would stay the same. >>> >>>> However automatically generating the user ABI from the kernel one >>>> might still be a good idea in the long run. >>> >>> My preference would be to try and use the kernel headers directly. >> >> I thought the same, especially after realizing that they are almost >> copy/paste from the vendor *-abi.h files. >> >>> >>> Jason From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760742AbcINIaX (ORCPT ); Wed, 14 Sep 2016 04:30:23 -0400 Received: from mail-db5eur01on0079.outbound.protection.outlook.com ([104.47.2.79]:14528 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1758116AbcINIaP (ORCPT ); Wed, 14 Sep 2016 04:30:15 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=matanb@mellanox.com; Subject: Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller To: Parav Pandit , Leon Romanovsky References: <20160901084406.GA4115@lst.de> <20160910161442.GC29259@lst.de> <20160910170151.GA5230@obsidianresearch.com> <20160911133421.GA23384@lst.de> <20160911143522.GL6415@leon.nu> <20160911171409.GA13442@obsidianresearch.com> <20160911172445.GA25953@lst.de> <20160911175235.GB13442@obsidianresearch.com> <20160912050717.GE8812@leon.nu> CC: Jason Gunthorpe , Christoph Hellwig , Tejun Heo , , , Linux Kernel Mailing List , , Li Zefan , Johannes Weiner , Doug Ledford , Liran Liss , "Hefty, Sean" , Haggai Eran , Jonathan Corbet , , , Or Gerlitz , Andrew Morton , From: Matan Barak Message-ID: <13a00119-e629-2d34-d08b-c02bb6beceea@mellanox.com> Date: Wed, 14 Sep 2016 11:14:03 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [193.47.165.251] X-ClientProxiedBy: AM5PR0901CA0040.eurprd09.prod.outlook.com (10.164.186.178) To DB5PR05MB1734.eurprd05.prod.outlook.com (10.165.7.16) X-MS-Office365-Filtering-Correlation-Id: 99aece1f-40b9-4262-aa39-08d3dc771b1e X-Microsoft-Exchange-Diagnostics: 1;DB5PR05MB1734;2:u3cGggSe/OQzMxhoIa99s4jtR5BaFaeBWkp4mUn/2qgO912vcEob42/c46pfBkyPQDoWYjvwfSNa5mgiro2yJKH8uytgyrTXXkbVS4UdnQWUfOw4CxD2534pYQ3KfpQLAHF1BwMgE0oHHcNDcMRk4yDSE9TrYyv5NVEbko6/DURoLyPF/l3jkS+rmqMZ6U/s;3:+Uvh0Q3fx9d1PNpdQWEQiXGPOqQfcmbfscwo7FJNwlsmWN1mBdGG3gsC+zgRpNllcC1k6yUYCeBYd1krW1ak8uy7ChOeW5LgPVd4UqPAJjMojfdlyZvIR+bIcfowS2q2 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR05MB1734; X-Microsoft-Exchange-Diagnostics: 1;DB5PR05MB1734;25:DjGh0rSE318u14SRN03f9agdlnO1ve2JBira3UxIjlExGU/dIsNorqH7JP8biVNnHuJqJ6CXZAU371U9eFrIzhtHe6zh07oYFcdKN/O3hTNBC/E8Z/23MVBuqW4u30wAVvBBdzI2yHxVQmtqLax+Yt4RSTfIvcrhjhAbUgu6Ewuk81zM1B4gz0IdxdYLV3zbmnYBEsIDpTa5lotBapF2hTtPvXykB7p30ndCQhAHCOwdqD9+xjJJNIj5tLosOHDyKJXK11ZIYEWCa6iujAXrzgNOUwybbemB9NOp70VoVylD7uS6o2zFY0VwhK3gbZGrINNeVB4FKlvgoJld9PA8w5GvJD0CfsOBDxkoeGKX1dqWF0iKf4bKuzHdTgC+W47bbQsnWAujmCCkxb7glRDNswM3AUXkGeOmRC0PaPRY3IbeukCJwnGP4pvETzqUzvCbbZ0+a57iNbuQ+isGspTbbUMl44FFMbGGgj11TvmwQiSIokRv9o1TAFKwpffXWEmsBnbuSTiDDzkvqiBleMo+y94eN40LdapMEcJ59XyM9FJ34yns/TART1gMoEAdKD8veXySOPQpCiPuGPbG6ee1gsRFhLEoEA3AMyraJrFn0WvwdLwFlQ6kOiXysXmEvvllV6/g4rejS3dfPH6/V3eXMMy2ppHERhDuQVWRfPktjgifmXqGErbWU2arrBhJjLmKHHEb7UzpsBjDlvLxVXEIFSZ10Fnq8jrt6zo7cgGZjpd4BFKQEBy9Qdly5Y1gjCvltyuG9ZMYlBmIbVs7QvuFMhWjJw0gcmjkfXRJJNz0D5sNbas02ae9BhhNETCJEWLDcx/V3KHX8P98ygkn8NMqYw== X-Microsoft-Exchange-Diagnostics: 1;DB5PR05MB1734;31:CM7yf8vgNnq0CXA5sFmoY9aiKn9Aa8w24j2JPn0QKWLzwJaJKHZ1RpEehgm3mHAZZrtoQcKQ29gsO1ndWzBOLkgP+53tYOTRw84OxGeMgFY7o+XKikUOgpsx/wusy8JY7MzwE35OnuaFSEr3ax9nLUEVnaYISGSqn68tuZ0Ad2az5os/6nA7FeflSrkMjV/Z3qtajqcF4Okh7mAj5WNtZLRznHU9oTgEoNU4S7Jr8pM=;20:TxV3GRvCEMGTh4U8/eXX7J3MT23hlUXjX2tAw7q9Piq8VFuj03kMYh9pXs001UN7GTEoDPO/Qm9PLqNDGmysVtht+qKGi/lpxLv6yUuqjnpbjet6kCaREWrQ+QkCzxM5tAuP6O0FXRfMlnpC/Ues7Y4zRqgNVMhvAqmdlAG0Jco+0DKgxeU6jVqa645TfCEIzGTKfbmhqlKmcgh2GkDLJo/zAi6sTepGgkwIgL4Uw0UxHwR/6YaAFUGLIHQIAv3N7LyP7tyYdC6zADYc/owwKLDsRU2KwoNOLRAJ5j+PpEbOw97U85IC1ujc45K0VrBIVXqqtFd8sQK3vN3B91nHb8dIl53KnVESb8M1CROuYXdSnqt9UiTyjtm6+Z1gM8uIB4b4Qk2gHGN4opjLZkRL35dRJ4CrL8El9k/HZ6Map4tzCw+dMe/E3jug30RD88+/JVzMIqiSF944ZtcLUj3nh4zNOnxQlGHgUL5/8el1BHCOPTwgYu0ANlTPXkucVHYE X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(17755550239193); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026);SRVR:DB5PR05MB1734;BCL:0;PCL:0;RULEID:;SRVR:DB5PR05MB1734; X-Microsoft-Exchange-Diagnostics: 1;DB5PR05MB1734;4:c1XIx0dQT4fdh9y28rZtmg2odNZTi3oqaGvTcm64w4ePzQHsnW4utPIKMo6Iy7Wys9sCC2GuvZL1BnCHyuY/yiRsButXWMs/1gIV8M4uysduKVgAIcxHDs2NCCWOhVEAf/LqOhrdBYWH1wH31TpuD+CAW3MU+LbjBKuWHMmT24bT6gSEEDpV6AYXnFR9BCkaLraH1LYdF4U9tCv2QsjK9XkHbvldeRQBwnS7s6YZYJZlbiXkcuVMH7+/Ph3ErPDaY3tddDqEo/zeFyp3dHfi/P/Os9vbZm8jC5jK0XdokiagO2X3QSvgQD9i26G4vYlMjpdKroNJgw79pZOcpB0XfruQh5vHrOgVS11vvLu8ParqA6jTCRkfJjuElDEZXFWwcX3hrzayKKsYpr4kqyTqVmeYiOWziX8CFHWDFBKv0baDDR40xsvnp8W4lFP3hESaIdvwhElY+QrrVb2CGgf2RA== X-Forefront-PRVS: 006546F32A X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6049001)(6009001)(7916002)(189002)(377454003)(199003)(24454002)(4326007)(2906002)(65826007)(81166006)(83506001)(101416001)(23676002)(106356001)(5660300001)(92566002)(47776003)(42186005)(31686004)(7846002)(2950100001)(93886004)(15975445007)(105586002)(65956001)(65806001)(66066001)(68736007)(64126003)(7416002)(50466002)(77096005)(189998001)(5001770100001)(305945005)(81156014)(19580405001)(4001350100001)(19580395003)(8676002)(33646002)(31696002)(7736002)(97736004)(230700001)(86362001)(3846002)(76176999)(50986999)(6116002)(586003)(36756003)(54356999);DIR:OUT;SFP:1101;SCL:1;SRVR:DB5PR05MB1734;H:[10.8.0.168];FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQUjA1TUIxNzM0OzIzOnFLaUpydUk1MU4xYkxYVCt2aXlMUWNvUHRv?= =?utf-8?B?bW4xUysvZDVzQSt5NnB2b1QrdnIydFVMcGVuZEt6TzJMZGNhY3VpNGJ0bC90?= =?utf-8?B?a2JJdkwyNmNudTJoMDVMcWNaNDRaZ3FwY1k5SU1Da3RudW1mZEVlSExRYmlN?= =?utf-8?B?d1ZISU1jRTZwU24zVnU5ZE1GMXdkb21uMm9tbFpnZXE2YU50Z2poajBodmNL?= =?utf-8?B?T216bHBHQmtkQjF0Ly9uZ3BqNHkzRlJ5WjRnNWo0a0cvSXYrYW9oOFZJcmJh?= =?utf-8?B?ellvdHNEZUMrMW9rZlNXTHo4Y01NN3dyMlpURnd1QjlJTUV0blhzZjhmOWxI?= =?utf-8?B?THphSGNvcjBKdUJzUDFZU1QrUmFZb2R3Y2R3VGdlTVJlVVp6elZqc3M3MmVU?= =?utf-8?B?eE50T0Y4UVV6azZvUU1JdExjQjVTU0czVDRkN2JrUVJaQm95dHE5S1ZjZ1Z3?= =?utf-8?B?RytsWmlwRWUzRk9IUGh5UVIzK0F1dWFFbG9DL0ZzaEY5SG0rK0VhelZSQ1VJ?= =?utf-8?B?R0MzSjdsOTJ4ZW1ycTFzWXh3bGMrSE9YaUIwN0NMaGZ5VmQ4RVYvTnhkbjMz?= =?utf-8?B?aVF6TUtTMGhrTGxoZkZMM3V4eFp1TWllQUQyWnFWSTdNQkN4UVRsaXZSZDJK?= =?utf-8?B?MDlGRnhrZzUrdmJoUFFZZGM4TTZ1SUkvcUdKeGV3bHFyTzVzVm4rTTk0T0Ri?= =?utf-8?B?TjhSYnQ1SHAwYzlmYlRLTTNMaWF5YU5VSG9hSnFFVnFZcFZrcEpwbGJ6VDk0?= =?utf-8?B?SkM5Tm50NVpJWGhBQitjckNhVHN2SUpvd1MzOW5RTEU2bVAxdno0VWVsUy93?= =?utf-8?B?YUFXTjNWOHFkcllzaVpHaUxmcTNWMmUraUg2bFhNMjg3YTRyYVdBSGUvQmZS?= =?utf-8?B?eC9OQ2NKS004cVNuOXUraFZtZDUrRHp6UkRDS05vQmppYVNuSWg0K2VOWkw4?= =?utf-8?B?VDdDN0NXUVlBYTBPN0JBVXIzZkpHSDZwQ0Q5WXg2NSt6WWtGZ1RxZ2pPWUhq?= =?utf-8?B?eDZCRE93NW53NlFLRjhDYjNDWkJwa00rTVV0bEg1ZmNjVHZ3cnFxbFBlY0ov?= =?utf-8?B?K3dkZHdMQVJKY05TeTc5aWwra3ppQmMwWUp1cmcxSEQ4ampoZU41eEpZUHY4?= =?utf-8?B?Yzk5b3BCK3FHajk4S0w3cUQza1ZlUXlnY3Z1ZWFkY1Q1ZXZvVWdzTlN5cExh?= =?utf-8?B?QjVBR0gwTStvdjZMa0ErcytkNnF6SEpRMElCckhrZ1RaT3lkNUovUTVVOHZ1?= =?utf-8?B?ZEFqQ3BacWUxK1V1emhiYzdabzJvdzBwRURjRGVYb3BnQ1kzQng3S3Z5QWlo?= =?utf-8?B?c25xVDMzZVZwNFgwTGhjNUl4cGdQQXlwZlU5WGpwK1ozT2JGNnNST3lCR3Y5?= =?utf-8?B?UTQ5SFkvUkQ0QXBXL0FKSlBzVWdaNWg3R243Y1FyYzg1bjdOenNxL0VUU0Q4?= =?utf-8?B?K1hjK3IrZ01SOUZlbmd0b2RXZVF0cERrQythcTQ5eGE5RjdlYmtUak4zODdq?= =?utf-8?B?RlpsMDFnKzl0ejVHeUFWVjYzMFhUWjdyMEhnNlFweis0N1g2KzJYS0VJRFcv?= =?utf-8?B?RCtZMkdGOWUwMTNwZFJ3T1E2T0phZ0llc0lJM3pISkNrZTQ1SVRPM0pEUDFK?= =?utf-8?B?OUhINWUrQzFlTFpGd2J2VjRRMElyZ3RERUgvMFJ3dUZSS3BXWUt4ak9OSzJ2?= =?utf-8?B?SVBDNTFkU2ViU0J1ZGdwamRxVlg3NU81dzVETDE4aEcvOG9yOUpjS0ttMzhx?= =?utf-8?B?ejJvREdlQUdHZi91V3lEdTdSRmVaLzd1UmtUTTlxR0RJMHY1bW1zLytTQlRa?= =?utf-8?B?QWJqSVQ4dFlnSnhIVU53OHVUUFlRMHRDU2l5VCtPUVllbWQ5MVc0SE1iM1A5?= =?utf-8?Q?vDd9wrLkI6M=3D?= X-Microsoft-Exchange-Diagnostics: 1;DB5PR05MB1734;6:Uv8B16E2bHaXQGeyN1oslsgL4zbYtEdYRV59sCKjD3PYztvqKTqQ/J047INbfH3zND05X8YjJrzIPErU1mOC4rs73ytTNcadqkNOEi2q5uPQ5uFDabwIs5HWp+j8MLOi2PTgJdXBqsEs2XxDWrDgdUenlgMwTDsgVfotoQJE9RoxYN4/NfbfUuvpUyEnwOkEXAX2oCWfs/1RmiNUFBLYcf40E/voXZJ7HkPj6pBZ87Hh1OrWSCXSq5/Yy1Tq2sScStJ7SlyQrSC8AiD1Z24gLEpQsAnYwYBZUj2eMbfQg5M1DjmnDfM9HEZuEyQc621XJjcmr8QhrDWCtaOELJl/fw==;5:ACH1NMBmi29K0eYsWaOgtT54pmMlrovbZ+52H4Q5MyEAluYBtRt+/xGVGy+tL1dwk9XM1336vckFHD1qOOKePsvNmy5G61ZKJFdVwimx7hJBx+2ygfrnS61YpsrWRD1eRiHHV8PgYGkC4OsPXeCLkg==;24:STxnZps0+4WlWDjWNU+FhWVtVTGq2BndgVJRKHHUFrKBylTzJGSh62MtaUVxUy869pVJz+zQRbdq2BdXDF07KBSGNDeCp/rFU0hfL/DThAo=;7:QqhQmzc8fe0EzULxLhESf2NujH5ZayR0nlDkMnRvJ2JuZ87fPakN459L4TUHcqByo+JgdCjhpAWv9xzFpNLe/7kCdAZuN0TKxiGMc02mWGorN+9rqPE0ji6oYSDWFE3MYV2fBWPjA+FQZHF7eY3UqjBne/7EdrW1ALmXcUoae73MCjvwQ0ZI6ZgZXEYEEF8j/oF50FELd27TJkRkO/Q1vEXkKg2n7N+7G8aE4H4jXHmhjQANDnC3khuF72SV/YNf SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2016 08:14:08.1377 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR05MB1734 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14/09/2016 10:06, Parav Pandit wrote: > Hi Dennis, > > Do you know how would HFI1 driver would work along with rdma cgroup? > > Hi Matan, Leon, Jason, > Apart from HFI1, is there any other concern? I just wonder how things like RSS will work. For example, a RSS QP doesn't really have a queue (if I recall, it's connected to work queues via an indirection table). So, when a user creates such a QP, do you want to account it as a regular QP? How are work queues accounted? > Or Patch is good to go? > > 4.8 dates are close by (2 weeks) and there are two git trees involved > (that might cause merge error to Linus) so if there are no issues, I > would like to make request to Doug to consider it for 4.8 early on. > > Parav > > On Mon, Sep 12, 2016 at 10:37 AM, Leon Romanovsky wrote: >> On Sun, Sep 11, 2016 at 11:52:35AM -0600, Jason Gunthorpe wrote: >>> On Sun, Sep 11, 2016 at 07:24:45PM +0200, Christoph Hellwig wrote: >>>>>>> I've posted some initial work toward a) a while ago, and once we >>>>> >>>>> Did it get merged? Do you have a pointer? >>>> >>>> http://www.spinics.net/lists/linux-rdma/msg31958.html >>> >>> Right, I remember that. Certainly the right direction >>> >>>>> However, everything under verbs is not straightforward. The files in >>>>> userspace are not copies... >>>>> >>>>> user: >>>>> >>>>> struct ibv_query_device { >>>>> __u32 command; >>>>> __u16 in_words; >>>>> __u16 out_words; >>>>> __u64 response; >>>>> __u64 driver_data[0]; >>>>> }; >>>>> >>>>> kernel: >>>>> >>>>> struct ib_uverbs_query_device { >>>>> __u64 response; >>>>> __u64 driver_data[0]; >>>>> }; >>>> >>>> We'll obviously need different strutures for the libibvers API >>>> and the kernel interface in this case, and we'll need to figure out >>>> how to properly translate them. I think a cast, plus compile time >>>> type checking ala BUILD_BUG_ON is the way to go. >>> >>> I'm not sure I follow, which would I cast? >>> >>> BUILD_BUG_ON(sizeof(ibv_query_device) == sizeof(ib_uverbs_cmd_hdr) + >>> sizeof(ib_uverbs_query_device)) >>> >>> ? >>> >>>>> I'm thinking the best way forward might be to use a script and >>>>> transform userspace into: >>>>> >>>>> struct ibv_query_device { >>>>> struct ib_uverbs_cmd_hdr hdr; >>>>> struct ib_uverbs_query_device cmd; >>>>> }; >>>> >>>> That would break the users of the interface. >>> >>> Sorry, I mean doing this inside rdma-plumbing. Since the change is ABI >>> identical the modified libibverbs would still be binary compatible >>> with all providers but not source compatible. Since all kernel >>> supported providers are in rdma-plumbing we can add the '.cmd.' at the >>> same time. >>> >>> The kernel uapi header would stay the same. >>> >>>> However automatically generating the user ABI from the kernel one >>>> might still be a good idea in the long run. >>> >>> My preference would be to try and use the kernel headers directly. >> >> I thought the same, especially after realizing that they are almost >> copy/paste from the vendor *-abi.h files. >> >>> >>> Jason