From patchwork Mon Jul 4 12:40:10 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Or Gerlitz X-Patchwork-Id: 9212543 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 46C6A60572 for ; Mon, 4 Jul 2016 12:40:15 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 362CF286A0 for ; Mon, 4 Jul 2016 12:40:15 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 28920286B5; Mon, 4 Jul 2016 12:40:15 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 929C7286A0 for ; Mon, 4 Jul 2016 12:40:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753759AbcGDMkN (ORCPT ); Mon, 4 Jul 2016 08:40:13 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:33414 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753756AbcGDMkM (ORCPT ); Mon, 4 Jul 2016 08:40:12 -0400 Received: by mail-oi0-f67.google.com with SMTP id w141so23035736oia.0 for ; Mon, 04 Jul 2016 05:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qtLrAjkYf7rpOCO+6QAvL1KAwmbhtkOWQy2Mu16kS4M=; b=n36IieyOJqtYxLhHVPOF2NXGbuL7HUtocewDeHIZ2MnJeRkUSMNKye4sLX3+RB9NGy F/hwF80Awsm7v1C/Opzf5IVJ+/P3HLgN0HlVJAxeFmbsfzFLQO4YzYEOgHOdBp1V0bPM guVHFm3rWSnRpgcEQydz9SBGPyiVNuO4KSCNM/0BURWUkIoIwLWw0BGFFeoBqSfqMR2H H2B0Mpvjn5eoLnhK945R/LkMG1ha01mb6jWgnLpxUDYEGIRcovx+GJTqIA6M2SgymMCj bn/0+cOSBJ4hV9vbwIJjqsmVzlSFa5yKBAgKU7aNk5Xiw1ykZgKlL8EdTfWr8IVVWEIH d2sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qtLrAjkYf7rpOCO+6QAvL1KAwmbhtkOWQy2Mu16kS4M=; b=WaVWlqtj/tisnrbvmifp3BffLRH8vPr6WhAf9I/nZxBYGsA0dzyoVzVdJuqvyora2T lX7FKiOdpXKHzLW2v/jSuHN5HYll8BtlmMIcWEqZpPc/EJSSgfEETwqYv16obRBIYqD1 YgrLJgY2TRC0cITjTS7y2CuvO4GXXM9RwtPy05JvnQjWjREi2ZU6inUqt7h9qvd86AID +Pe10NdnI+x7TuXsxmhN+3eqq7UrKAqeyFL7H6DzZtg0r6cT6PfvOvZu2E2/7AorW/Ug B7o81vXY7ncKHsOnatYtOs26jqOat13XeAAXCycJ+Ulq99B36yKLqcvw5XwFQybhUGUt KX7w== X-Gm-Message-State: ALyK8tJuJ6DT595RLlEAJ8Hpxa9L7meBdpPUKJg1AcnONxhpjRYUkQqjDA/qHoFiOye8anjb3BW/w34eH2IxfA== X-Received: by 10.202.196.14 with SMTP id u14mr6555962oif.136.1467636011214; Mon, 04 Jul 2016 05:40:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.86.97 with HTTP; Mon, 4 Jul 2016 05:40:10 -0700 (PDT) In-Reply-To: <20160704045111.GA5289@leon.nu> References: <1467550074-24061-1-git-send-email-leon@kernel.org> <1467550074-24061-3-git-send-email-leon@kernel.org> <20160704045111.GA5289@leon.nu> From: Or Gerlitz Date: Mon, 4 Jul 2016 15:40:10 +0300 Message-ID: Subject: Re: [PATCH for-next 2/2] IB/core: Support for CMA multicast join flags To: Leon Romanovsky Cc: Alex Vesker , Doug Ledford , "linux-rdma@vger.kernel.org" Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, Jul 4, 2016 at 7:51 AM, Leon Romanovsky wrote: > On Sun, Jul 03, 2016 at 04:46:23PM +0300, Or Gerlitz wrote: >> On Sun, Jul 3, 2016 at 3:47 PM, Leon Romanovsky wrote: >> > From: Alex Vesker >> > >> >> > drivers/infiniband/core/cma.c | 98 +++++++++++++++++++++++++++++++++++++--- >> > drivers/infiniband/core/ucma.c | 18 ++++++-- >> > include/rdma/ib_sa.h | 5 ++ >> > include/rdma/rdma_cm.h | 4 +- >> > include/uapi/rdma/rdma_user_cm.h | 9 +++- >> > 5 files changed, 122 insertions(+), 12 deletions(-) >> >> >> For the ease/robustness of review for UAPI changes, we have a long >> time common practice >> to break things like this one to IB core kernel only patch, and one >> that deals the user-space > You are right, this practice exists and we are following it as much as it makes sense. > This specific case doesn't need to be separated, because it introduces one logical > change and separate patches will be useless as standalone patches. Leon, The point is that you need to get people to be used to that practice, and it seems we're not doing that. Otherwise I wouldn't have to chat for 20m with 2-3 people that wonder why I made these comments. I think we should require it from the developers, period and not argue on that. B/c in bunch of other places, it is totally required, for example, here you could just carve this small piece to be part of your UAPI patch, what's wrong with that? > All properties which we are looking in the patch (correct logic, bisectable, > buildable and easy reviewable) exist in this patch. read above. This is (1) needed for robust bisection (2) team education >> facing things (e.g here ucma.c and rdma_user_cm.h), please do that. > We will be happy to hear other feedback as well. feel free to hear and hear but please address the arguments brought here Or. --- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- a/include/uapi/rdma/rdma_user_cm.h +++ b/include/uapi/rdma/rdma_user_cm.h @@ -244,12 +244,19 @@ struct rdma_ucm_join_ip_mcast { __u32 id; }; struct rdma_ucm_join_mcast { __u64 response; /* rdma_ucma_create_id_resp */ __u64 uid; __u32 id; __u16 addr_size; - __u16 reserved; + __u16 join_flags; struct sockaddr_storage addr; }; basically it would be good to have the ucma part there as well, but if you and Co can't come up with patch planning that allows that is bisects, lets it be just the header file. This way we come with strict message to the developers that we want them to break patches to non-UAPI and yes-UAPI + user-space facing and have them to stop argue and complain.