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.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 4AB28C43381 for ; Wed, 20 Mar 2019 20:23:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F1B442184D for ; Wed, 20 Mar 2019 20:23:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="qrfa2/Pe" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727159AbfCTUXF (ORCPT ); Wed, 20 Mar 2019 16:23:05 -0400 Received: from mail-qt1-f181.google.com ([209.85.160.181]:46950 "EHLO mail-qt1-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726846AbfCTUXF (ORCPT ); Wed, 20 Mar 2019 16:23:05 -0400 Received: by mail-qt1-f181.google.com with SMTP id z17so3122972qts.13 for ; Wed, 20 Mar 2019 13:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=dAuv15Vu3K85abrHQ8aoRlk1ZdTy9YNVvP4fenUnZaw=; b=qrfa2/PeEBN5EyNRoRwU05N5aLqBSwQsTftdHgcOsHnyUaGsPYaWmS24OM+8eINJgN WFjUIzPbu3tJf9PrkQdycemFb/NT8/7bVKhv0qHRREZnDAm1iBv1VFcMwvHDmIo3MZGk tvSLrq2xCfhN3BdxLhebvG+3WJjHqXAo/dXOH+BMA3Fk2JuEBT5PH5MyObeuCck44w/f w95F/uVDwABhoihkoBO/3z5g3w86TPDLyW9K9K6MkEDXlLOiMmdIILh2Sr9P1iT6u6a0 1cucqh/1kStWF8yUS5zqtUJnkNY6yZlZCrobMKCx7hjwSzd03zE4YGHBEUSc6mX3uzJ/ 2l+Q== 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:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=dAuv15Vu3K85abrHQ8aoRlk1ZdTy9YNVvP4fenUnZaw=; b=HMgalOGLsYM30paREJYM3F4a8zV6BGJmbMd88h6ColPh5/ISWKR/VPZtlLN1b1HDIy PLjWm4WEG7LTH88nRWKHQLUGJNQmWWKndWClRyUNa9Hz3YyJ4wZ+lIMICRe+CrG78aQY jXrBIp7+hfXu5pMvhZb6ELSACX1Y1glRhPz9xfsSxCZZBAGBbHZcah0qRKytJtGKj0nT FgZ4l9nBNZHuWagiOLK3jWaHlLalWvk8n6bri9UI4uLbUaGPlOL22jKXyMiUXRM7yzMX KFWmnRnzx4kjszFTh+IoKFTiVXtnFI5Ruo9YtQlgytvafYTUpNdyQGPUjtg4Xiu/lMkO malg== X-Gm-Message-State: APjAAAUvoYYRz8LSsuD6UVOpmZ16VQxiHc1BGUsGatjCv6NjflTi9anb VP021mBqPcXdtKRlMrDw+guurhY2Tw8= X-Google-Smtp-Source: APXvYqzYX0jNoB5umsD0xNabc/lZtAS5llZK1BWsc9eeg+bf/ERYuIbggaD/FG+Z9GenrWgK+uU1Sg== X-Received: by 2002:a0c:d21a:: with SMTP id m26mr8391596qvh.100.1553113383941; Wed, 20 Mar 2019 13:23:03 -0700 (PDT) Received: from cakuba.netronome.com ([66.60.152.14]) by smtp.gmail.com with ESMTPSA id 92sm1798319qtc.97.2019.03.20.13.23.02 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 20 Mar 2019 13:23:03 -0700 (PDT) Date: Wed, 20 Mar 2019 13:22:57 -0700 From: Jakub Kicinski To: Parav Pandit Cc: Jiri Pirko , "Samudrala, Sridhar" , "davem@davemloft.net" , "netdev@vger.kernel.org" , "oss-drivers@netronome.com" Subject: Re: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI ports Message-ID: <20190320132257.372369d7@cakuba.netronome.com> In-Reply-To: References: <20190314150945.031d1b08@cakuba.netronome.com> <20190315200814.GD2305@nanopsycho> <20190318122105.GH2270@nanopsycho> <20190318123634.6e90c043@cakuba.netronome.com> <20190318125935.580c8fbe@cakuba.netronome.com> <20190318142949.36f18af4@cakuba.netronome.com> Organization: Netronome Systems, Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, 20 Mar 2019 18:24:15 +0000, Parav Pandit wrote: > Hi Jiri, Jakub, Samudrala Sridhar, > > > > > > And physical port in include/uapi/linux/devlink.h also describe > > > > > > that. > > > > > > > > > > By "that" you must mean that the physical is a user facing port. > > > > > > > > Can you please describe the difference between 'PF port' and > > > > 'physical port of include/uapi/linux/devlink.h'? I must have missed > > > > this crisp definition in discussion between you and Jiri. I am in > > > > meantime checking the thread. > > > > > > Perhaps start with the cover letter which includes an ASCII drawing? > > > > > > Using Mellanox nomenclature - PF port is a "representor" for the PF > > > which may be on another Host (SmartNIC or multihost). It's pretty > > > much the same thing as a VF port/"representor". > > > > > Yes. We are aligned here. :-) > > I see your point, where in multi-host scenario, a physical port may be 1, but > > PF ports are 4, because of 4 PFs for 4 hosts. > > (just an example of 4 hosts with their own mac address sharing 1 physical > > port). > > > > When there is no multihost and one to one mapping between a PF and > > physical links, there is some overlap between PF port and physical port > > attributes. > > I believe, such overlap is fine as long as we have unique indices for the ports. > > > > So I am ok to have flavours as physical/cpu/dsa/pf/vf/mdev/switchport. > > (last 4 as new port flavours). > > > > > Physical port is the hole on the panel of the adapter where cable goes. > > So my take away from above discussion are: > 1. Following new port flavours should be added pci_pf/pci_vf/mdev/switchport. > a. Switchport indicates port on the eswitch. Normally this port has rep-netdev attached to it. I don't understand the "switchport". Surely physical ports are also attached to the eswitch? And one of the main purpose of adding the pci_pf/pci_vf flavours was to generate phys_port_name for the port netdevs. Please don't use the term representor if possible. Representor for most developers describes the way the netdev is implemented in the driver, so for Mellanox and Netronome different ports will be representors and non-representors. That's why I prefer port netdev (attached to eswitch, has switch_id) and host netdev (PF/VF netdev, vNIC, VSI, etc). > b. host side port flavours are pci_pf/pci_vf/mdev which may be connected to switchport See above, pci_pf/pci_vf are needed for phys_port_name generation. > 2. host side port flavours are not limited to Ethernet, as it is for devlink's port instance. > > 3. Each port is continue to be accessed using unique port index. > > 4. host side ports and switchport are control objects. > a. switch side ports reside where current eswitch object of devlink instance reside > b. for a given VF/PF/mdev such host side ports may be in hypervisor or VM or both > depending on the privilege > > 5. eth.mac_address, rdma.port_guid can be programmed at > host port flavours by extending as $ devlink port param set... > (similar to devlink dev param set) You can keep restating that's your position, but I have *not* conceded to that. > 6. more host port params can be added in future when user need arise > > 7. rep-netdev continue to be eswitch (switchport) representor at the switch side. > a. Hence rep-netdev cannot be used for programming host port's parameters. > > 8. eswitch devlink instance knows when VF/PF/mdev's switchport are created/removed. > Hence, those will be created/deleted by eswitch. > Similarly for host port flavours too. > > Does it look fine? Did I miss something? > We would like to progress on incremental patches for item-4 and > any prep work needed to reach to item-4.