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=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 8112BC17441 for ; Sat, 9 Nov 2019 00:57:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4BC6B214DA for ; Sat, 9 Nov 2019 00:57:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="h4qr1KxZ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726133AbfKIA5K (ORCPT ); Fri, 8 Nov 2019 19:57:10 -0500 Received: from mail-qt1-f193.google.com ([209.85.160.193]:33716 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725895AbfKIA5K (ORCPT ); Fri, 8 Nov 2019 19:57:10 -0500 Received: by mail-qt1-f193.google.com with SMTP id y39so8753964qty.0 for ; Fri, 08 Nov 2019 16:57:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=VuQrMxWBxO6EoV/i1I70FM4gejpCWbnlTsIzbiitkKw=; b=h4qr1KxZ3XNnC+jXtuxPRFXMOnak60RHW2iWRXsgbjeBZc34SAWLDFquD64WYuwycq 8Ke00fCQS+xYkvq/VMGYtZTkeq5C4rTFwHUU+/SLtom3DqZfAHKXX9shV4dCILHI9TJk VyoGcxT9dDwW9xgkATwDHK0ZgCGToxBG2B1B4EtFuV71F4jOUEz3PPn+Zma7YOUq5poP 1HuXFvs3ig2p+BM3KW15n8w+bTqiX9VIcpsl8rSRb6Q80MNeRhNGBOoYOLXqcyK4Gsk4 WhnoDW7jwRoaElJiJonLVlB9k4TKTPLK1RMyobAWgnuZgV/hwz2ekxqwKxk3L5bQ3X2V EVNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=VuQrMxWBxO6EoV/i1I70FM4gejpCWbnlTsIzbiitkKw=; b=f/kHfs2SGqRXQ64o/ai9ccLdAKS7PrtN6zz3E/tEBf8gD8JG1c5yQKxgppFYpEivGc zJu4q+ZbQNqXKoV7XDXytOeBcPhxUfqDddyOawom3cBq87HPEWKe6fE2pGcMEicWq0fp oCyR+IO+dkrSzxAz6WPVMAdhR24T7PWJ4OrZB1hEW9jfH0Jr8AHs/gNluNz37FeNIg1Z PZ3UVzA1C54lzIeMlz4n+wPN9VdhR9B8lipDV6mvwayIXzosZTSZ6aZxWYXcRju99pMg xa0FYzGnZmhP+IwBe6mjBpADlMDQxKw/VyUy0CEeaxqgdAkCFZgLI9lBSVZ0CGHfIpue vMWg== X-Gm-Message-State: APjAAAXa20s23/L9+Jpl9K42hlv4XQTfn9MKthC2YZPg6ziXH70aC84t 7vGtWrdAIf8fHjTJ6iXt/uL41g== X-Google-Smtp-Source: APXvYqxs5fv/Czk0u6Tq8dTd/u4S8g8hDvWuHaY0HMCDHty7xYz8WVMHbxQhmupy/IfwHd7AiQeq5Q== X-Received: by 2002:ac8:608:: with SMTP id d8mr14458157qth.258.1573261029435; Fri, 08 Nov 2019 16:57:09 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-113-180.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.113.180]) by smtp.gmail.com with ESMTPSA id u9sm4353467qke.50.2019.11.08.16.57.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 08 Nov 2019 16:57:08 -0800 (PST) Received: from jgg by mlx.ziepe.ca with local (Exim 4.90_1) (envelope-from ) id 1iTF3s-0001G7-Bx; Fri, 08 Nov 2019 20:57:08 -0400 Date: Fri, 8 Nov 2019 20:57:08 -0400 From: Jason Gunthorpe To: Parav Pandit Cc: Alex Williamson , Jakub Kicinski , Jiri Pirko , David M , "gregkh@linuxfoundation.org" , "davem@davemloft.net" , "kvm@vger.kernel.org" , "netdev@vger.kernel.org" , Saeed Mahameed , "kwankhede@nvidia.com" , "leon@kernel.org" , "cohuck@redhat.com" , Jiri Pirko , "linux-rdma@vger.kernel.org" , Or Gerlitz , "Jason Wang (jasowang@redhat.com)" Subject: Re: [PATCH net-next 00/19] Mellanox, mlx5 sub function support Message-ID: <20191109005708.GC31761@ziepe.ca> References: <20191107153234.0d735c1f@cakuba.netronome.com> <20191108121233.GJ6990@nanopsycho> <20191108144054.GC10956@ziepe.ca> <20191108111238.578f44f1@cakuba> <20191108201253.GE10956@ziepe.ca> <20191108133435.6dcc80bd@x1.home> <20191108210545.GG10956@ziepe.ca> <20191108145210.7ad6351c@x1.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On Fri, Nov 08, 2019 at 10:48:31PM +0000, Parav Pandit wrote: > We should be creating 3 different buses, instead of mdev bus being de-multiplexer of that? > > Hence, depending the device flavour specified, create such device on right bus? > > For example, > $ devlink create subdev pci/0000:05:00.0 flavour virtio name foo subdev_id 1 > $ devlink create subdev pci/0000:05:00.0 flavour mdev subdev_id 2 > $ devlink create subdev pci/0000:05:00.0 flavour mlx5 id 1 subdev_id 3 I like the idea of specifying what kind of interface you want at sub device creation time. It fits the driver model pretty well and doesn't require abusing the vfio mdev for binding to a netdev driver. > $ devlink subdev pci/0000:05:00.0/ config > $ echo /bind Is explicit binding really needed? If you specify a vfio flavour why shouldn't the vfio driver autoload and bind to it right away? That is kind of the point of the driver model... (kind of related, but I don't get while all that GUID and lifecycle stuff in mdev should apply for something like a SF) > Implement power management callbacks also on all above 3 buses? > Abstract out mlx5_bus into more generic virtual bus (vdev bus?) so > that multiple vendors can reuse? In this specific case, why does the SF in mlx5 mode even need a bus? Is it only because of devlink? That would be unfortunate Jason