From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 975FBC433E0 for ; Fri, 3 Jul 2020 06:28:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 65E62204EA for ; Fri, 3 Jul 2020 06:28:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593757695; bh=57k3H5N/CoCyneU8xje2Gdy9cNE/mU+s8od4ztCbvj4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=ACrkSaZXnDg//BnuPGkmBOO5VHf9d7p31RkaEA/xewNTfmbJj2dS4FuJ8hJDfrhHu P4CGFj6aZ/NV2AckAVhjfAWLG65QsrA9QX1ggmapBxGyc+XQw/LVWjuK9+2w6P3cdc /VK2mSxdp3bRiycvibYAk8avRF0QcaRn0bvr17aY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726358AbgGCG2N (ORCPT ); Fri, 3 Jul 2020 02:28:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:41830 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726347AbgGCG2N (ORCPT ); Fri, 3 Jul 2020 02:28:13 -0400 Received: from localhost (unknown [213.57.247.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 32D3320772; Fri, 3 Jul 2020 06:28:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593757692; bh=57k3H5N/CoCyneU8xje2Gdy9cNE/mU+s8od4ztCbvj4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=sCnqUW+Z7wqN9ZERHApQrmABBYmapyCsLNkaH4yNkk/HhmRUFcds5rOiba/amZf3H STwxooyjFcVgKDTLGLsyjdRmT+hGO1cSA2AkOH+PjQV4j2wteUMhsDAMZWQShN2jmI bWt++1YZ54KgS2XKUj++k2qg63cwki79fmsDx3JY= Date: Fri, 3 Jul 2020 09:28:09 +0300 From: Leon Romanovsky To: Jason Gunthorpe Cc: Doug Ledford , Feras Daoud , Jakub Kicinski , linux-rdma@vger.kernel.org, Michael Guralnik , netdev@vger.kernel.org, Saeed Mahameed Subject: Re: [PATCH rdma-next 0/2] Create IPoIB QP with specific QP number Message-ID: <20200703062809.GG4837@unreal> References: <20200623110105.1225750-1-leon@kernel.org> <20200702175541.GA721759@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200702175541.GA721759@nvidia.com> Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On Thu, Jul 02, 2020 at 02:55:41PM -0300, Jason Gunthorpe wrote: > On Tue, Jun 23, 2020 at 02:01:03PM +0300, Leon Romanovsky wrote: > > From: Leon Romanovsky > > > > >From Michael, > > > > This series handles IPoIB child interface creation with setting > > interface's HW address. > > > > In current implementation, lladdr requested by user is ignored and > > overwritten. Child interface gets the same GID as the parent interface > > and a QP number which is assigned by the underlying drivers. > > > > In this series we fix this behavior so that user's requested address is > > assigned to the newly created interface. > > > > As specific QP number request is not supported for all vendors, QP > > number requested by user will still be overwritten when this is not > > supported. > > > > Behavior of creation of child interfaces through the sysfs mechanism or > > without specifying a requested address, stays the same. > > > > Thanks > > > > Michael Guralnik (2): > > net/mlx5: Enable QP number request when creating IPoIB underlay QP > > RDMA/ipoib: Handle user-supplied address when creating child > > Applied to for-next, thanks Thanks Jason, Won't it better that first patch be applied to mlx5-next in order to avoid possible merge conflicts? Thanks > > Jason