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.5 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT 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 BCEA7C43381 for ; Thu, 21 Mar 2019 09:19:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 765B9218A2 for ; Thu, 21 Mar 2019 09:19:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=resnulli-us.20150623.gappssmtp.com header.i=@resnulli-us.20150623.gappssmtp.com header.b="YJCu2X0L" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728149AbfCUJTF (ORCPT ); Thu, 21 Mar 2019 05:19:05 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:33264 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726253AbfCUJTE (ORCPT ); Thu, 21 Mar 2019 05:19:04 -0400 Received: by mail-wm1-f67.google.com with SMTP id z6so1610548wmi.0 for ; Thu, 21 Mar 2019 02:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=HRLAv/6C5414+Z6/WvomUJfDW86wWujJfU2bMhyIMPk=; b=YJCu2X0LlpoSy2FgmzfBMf6Dk7KEQYHx5WVOsPPgOtz02WYVAa6sbMO0lLus06kEpQ fGvGxrbK70BQCuLh16yV6kQmiu5cjUChTwCVu3ANrkjIX0svty/utBXQ/e8lRVox47N/ cRgvTbcuSV/KYe4qXzN5z+R2DJSsExhbU/eRcg9G5CXgEB4SpAc+/Dq13kmIOaa8/WS5 whOwfE85VPlOKb8l4p1lTrmAiX/0KOT9GK6WN1D1bPTN9ATeXnRvCMufZ2DxlbWsfJE7 q+LQuVTQD47lIR5AxO3edJod7B3XU7KgHOoXEfp7aNQZoMrCALcg+kBBuc8ATFi0I8Vs RU9w== 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=HRLAv/6C5414+Z6/WvomUJfDW86wWujJfU2bMhyIMPk=; b=uXpmSczDM+dflLi7ByuWJomZ7h6jKegp53GOCAuqm368ErCH+jHqiTi+cFAjbI+Nen 0HoX8A/vRMtW0ZDd1JB1CktV/cy06SMzJMCQcw58u7l1q6glTe9ByxWG4pVMOoA3yIu+ wiQeCS968B2s1K2FDUIHPr5Kbj9WX2L6hNGzzocaXHuU0tYRZga3PzaJXYapjjv006tE 5gCnwUoorTyusBV+wEKe0VySxrqK4WxYIdIrfKC7vSTxPVUQKhLIuu6mEd9kxWbzNb+u ZMOOjhXMAyfI1tDbB5gWX6e1+xAjcBjETY5AsTzHDxpvYpKP9qfWh6oEN7ty3k3yaCA2 jhuw== X-Gm-Message-State: APjAAAXg9letEAa71J2xnWeWx4Asi+bUVNY9tmZDgsWlw8XsVNC/5KXJ 6dqa90bFEANZ9OriVnxkmsU/zLwRu7g= X-Google-Smtp-Source: APXvYqygQh/bELnjpX2zehP62NwJAv8OEZQKE7N+cBJPKjeZF1UZlFFGyr7Hc/3IKIWY+GCnTxASog== X-Received: by 2002:a7b:c94c:: with SMTP id i12mr1728722wml.115.1553159942229; Thu, 21 Mar 2019 02:19:02 -0700 (PDT) Received: from localhost ([195.39.71.253]) by smtp.gmail.com with ESMTPSA id q24sm5525120wmq.5.2019.03.21.02.19.01 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 21 Mar 2019 02:19:01 -0700 (PDT) Date: Thu, 21 Mar 2019 10:08:21 +0100 From: Jiri Pirko To: Jakub Kicinski Cc: Parav Pandit , "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: <20190321090821.GB2087@nanopsycho> References: <20190318123634.6e90c043@cakuba.netronome.com> <20190318125935.580c8fbe@cakuba.netronome.com> <20190318142949.36f18af4@cakuba.netronome.com> <20190320132257.372369d7@cakuba.netronome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190320132257.372369d7@cakuba.netronome.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Wed, Mar 20, 2019 at 09:22:57PM CET, jakub.kicinski@netronome.com wrote: >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. Yep, that makes sense. > >> 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. I'm also not convinced that host dummy ports are good idea to hold these. > >> 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.