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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 8ABF2C2D0E4 for ; Thu, 19 Nov 2020 06:22:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2736E246DE for ; Thu, 19 Nov 2020 06:22:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="lkZI1WJm" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726334AbgKSGWy (ORCPT ); Thu, 19 Nov 2020 01:22:54 -0500 Received: from mail.kernel.org ([198.145.29.99]:53624 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726200AbgKSGWy (ORCPT ); Thu, 19 Nov 2020 01:22:54 -0500 Received: from lt-jalone-7480.mtl.com (c-24-6-56-119.hsd1.ca.comcast.net [24.6.56.119]) (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 9E4BE246AD; Thu, 19 Nov 2020 06:22:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605766973; bh=Flg8FSn6jtiUD6lsTxWCt3rDnH7Rd+y0XZDO992S1sI=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=lkZI1WJm47cDfpIAyS6iqYxQvs8isYaqF139cwwN+uUR7p+VZ0HplLmywEA9rlk+w SjytbsoYUF+A79rbp0WeYGbTFg8aqNRAse2Z0/Ot5DoYYYKlVjswWa1x7NoKt0FIL0 ktH3LUaXKA99fxGGyuiwCNO70qaiel8EkQMRDXjQ= Message-ID: <28239ff66a27c0ddf8be4f1461e27b0ac0b02871.camel@kernel.org> Subject: Re: [PATCH net-next 00/13] Add mlx5 subfunction support From: Saeed Mahameed To: Jakub Kicinski , Parav Pandit Cc: "netdev@vger.kernel.org" , "linux-rdma@vger.kernel.org" , "gregkh@linuxfoundation.org" , Jiri Pirko , Jason Gunthorpe , "dledford@redhat.com" , Leon Romanovsky , "davem@davemloft.net" Date: Wed, 18 Nov 2020 22:22:51 -0800 In-Reply-To: <20201118182319.7bad1ca6@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> References: <20201112192424.2742-1-parav@nvidia.com> <20201116145226.27b30b1f@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20201116175804.15db0b67@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20201117091120.0c933a4c@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> <20201118182319.7bad1ca6@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, 2020-11-18 at 18:23 -0800, Jakub Kicinski wrote: > On Tue, 17 Nov 2020 18:50:57 +0000 Parav Pandit wrote: > > At this point vdpa tool of [1] can create one or more vdpa net > > devices on this subfunction device in below sequence. > > > > $ vdpa parentdev list > > auxiliary/mlx5_core.sf.4 > > supported_classes > > net > > > > $ vdpa dev add parentdev auxiliary/mlx5_core.sf.4 type net name > > foo0 > > > > $ vdpa dev show foo0 > > foo0: parentdev auxiliary/mlx5_core.sf.4 type network parentdev > > vdpasim vendor_id 0 max_vqs 2 max_vq_size 256 > > > > > I'm asking how the vdpa API fits in with this, and you're showing > > > me the two > > > devlink commands we already talked about in the past. > > Oh ok, sorry, my bad. I understood your question now about relation > > of vdpa commands with this. > > Please look at the above example sequence that covers the vdpa > > example also. > > > > [1] > > https://lore.kernel.org/netdev/20201112064005.349268-1-parav@nvidia.com/ > > I think the biggest missing piece in my understanding is what's the > technical difference between an SF and a VDPA device. > Same difference as between a VF and netdev. SF == VF, so a full HW function. VDPA/RDMA/netdev/SCSI/nvme/etc.. are just interfaces (ULPs) sharing the same functions as always been, nothing new about this. Today on a VF we load a RDMA/VDPA/netdev interfaces SF will do exactly the same and the ULPs will simply load, and we don't need to modify them. > Isn't a VDPA device an SF with a particular descriptor format for the > queues? No :/, I hope the above answer clarifies things a bit. SF is a device function that provides all kinds of queues.