From mboxrd@z Thu Jan 1 00:00:00 1970 From: Parav Pandit Subject: Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller Date: Wed, 14 Sep 2016 12:36:19 +0530 Message-ID: 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 Return-path: In-Reply-To: <20160912050717.GE8812-2ukJVAZIZ/Y@public.gmane.org> Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Leon Romanovsky Cc: Jason Gunthorpe , Christoph Hellwig , Matan Barak , Tejun Heo , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Kernel Mailing List , linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Li Zefan , Johannes Weiner , Doug Ledford , Liran Liss , "Hefty, Sean" , Haggai Eran , Jonathan Corbet , james.l.morris-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org, Or Gerlitz , Andrew Morton , linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-rdma@vger.kernel.org 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? 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 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759415AbcINHG0 (ORCPT ); Wed, 14 Sep 2016 03:06:26 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:35295 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751790AbcINHGV (ORCPT ); Wed, 14 Sep 2016 03:06:21 -0400 MIME-Version: 1.0 In-Reply-To: <20160912050717.GE8812@leon.nu> 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> From: Parav Pandit Date: Wed, 14 Sep 2016 12:36:19 +0530 Message-ID: Subject: Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller To: Leon Romanovsky Cc: Jason Gunthorpe , Christoph Hellwig , Matan Barak , 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? 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