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, 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 33C4BC43381 for ; Sat, 2 Mar 2019 09:51:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EE79920836 for ; Sat, 2 Mar 2019 09:51:11 +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="q+GJgmS4" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726336AbfCBJvK (ORCPT ); Sat, 2 Mar 2019 04:51:10 -0500 Received: from mail-wr1-f68.google.com ([209.85.221.68]:44609 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726044AbfCBJvK (ORCPT ); Sat, 2 Mar 2019 04:51:10 -0500 Received: by mail-wr1-f68.google.com with SMTP id w2so356785wrt.11 for ; Sat, 02 Mar 2019 01:51:09 -0800 (PST) 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=nWX0Q9+nM6AXnELpS/bYw6Ns8V6ZZ4QdHp0j58ygMl8=; b=q+GJgmS4u95q/CvusINwoys2SwhkIkP0O5HlRK/u6NTaZuQQ52Pv7Ym9JfPMn3+Ea9 7tj2xIwVDl1aI2jw4AMu4E2tmx8p0vNjo0iw7FzpR+uGfs1XdpExb5X1yhlzWEZe6t1w E2hNa+DFdEWQTCpC+0ZdkJz1f9tDFy5hXxuEau2P8z4V1ajq7AzZZsLekifTd/qw2d42 YBqt/tLgKM0n5nljtTf3Am2c4qOqvHPTvayH9K20r3WyrWB9bQgdMvadBVKuOcN7wNkx acg9sYBrKGIVsPzz2r43iR5BR8bwgyR1lyTHs5RXB3tz7Sea1ZvmczMtN9NK3NqActXx ijeA== 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=nWX0Q9+nM6AXnELpS/bYw6Ns8V6ZZ4QdHp0j58ygMl8=; b=s+iS3/Mfte4lHcU9MC1zCxbydFTFYRl9MwHexSM/nXoUfr1OrTyHFO4E+1/FGAOfT8 b5dtOH8iU59OBh1LYgvzanV3GkyC882ZTOabpXQDnmIFvjOJYU8NhNkY5/soR/1kVJzn iSsdDaTV3WPn0hEeBdeQjJb6mARMfexCGXrec5nDo2PWnO9T6u9Ak/rfxjNzhF3GbZxb kAXDfEeutP2QtQrMfFlyouOOkVdmk5LijPU+zK/SQ4QYcfP7b1ZORCErN1H5s1Sr5pAD wNmDWLhx6avre12vgBx9z+LsQJJPhBBQgd42aRnhJfoH2/AePd/+y1Ronkn+bnnERuJl 4tUA== X-Gm-Message-State: APjAAAU/7NSQCEe8rnF0fRoFiF1lnSh7IIL2X8VrWEAMnFrbf3PplR7m QS8lgSnfeZAhhosUbRycA3LNug== X-Google-Smtp-Source: APXvYqyR6XuRhXvZq1kvQrVrZ6W7wEAEknChJsy5HUblhkSIJ4NJ1oaDC6dHktDuvFiXt3oCRfuOWQ== X-Received: by 2002:a05:6000:1110:: with SMTP id z16mr6443200wrw.28.1551520268545; Sat, 02 Mar 2019 01:51:08 -0800 (PST) Received: from localhost (ip-89-177-134-16.net.upcbroadband.cz. [89.177.134.16]) by smtp.gmail.com with ESMTPSA id c8sm383630wrx.6.2019.03.02.01.51.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 02 Mar 2019 01:51:07 -0800 (PST) Date: Sat, 2 Mar 2019 10:41:16 +0100 From: Jiri Pirko To: Jakub Kicinski Cc: 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: <20190302094116.GQ2314@nanopsycho> References: <20190301180453.17778-1-jakub.kicinski@netronome.com> <20190301180453.17778-5-jakub.kicinski@netronome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190301180453.17778-5-jakub.kicinski@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 Fri, Mar 01, 2019 at 07:04:50PM CET, jakub.kicinski@netronome.com wrote: >PCI endpoint corresponds to a PCI device, but such device >can have one more more logical device ports associated with it. >We need a way to distinguish those. Add a PCI subport in the >dumps and print the info in phys_port_name appropriately. > >This is not equivalent to port splitting, there is no split >group. It's just a way of representing multiple netdevs on >a single PCI function. > >Note that the quality of being multiport pertains only to >the PCI function itself. A PF having multiple netdevs does >not mean that its VFs will also have multiple, or that VFs >are associated with any particular port of a multiport VF. > >Example (bus 05 device has subports, bus 82 has only one port per >function): > >$ devlink port >pci/0000:05:00.0/0: type eth netdev enp5s0np0 flavour physical >pci/0000:05:00.0/10000: type eth netdev enp5s0npf0s0 flavour pci_pf pf 0 subport 0 >pci/0000:05:00.0/4: type eth netdev enp5s0np1 flavour physical >pci/0000:05:00.0/11000: type eth netdev enp5s0npf0s1 flavour pci_pf pf 0 subport 1 So these subport devlink ports are eswitch ports for subports, right? Please see the following drawing: +---+ +---+ +---+ pfsub| 5 | vf| 6 | | 7 |pfsub +-+-+ +-+-+ +-+-+ physical link <---------+ | | | | | | | | | | | | | | | +-+-+ +-+-+ +-+-+ +-+-+ | 1 | | 2 | | 3 | | 4 | +--+---+------+---+------+---+------+---+--+ | physical pfsub vf pfsub | | port port port port | | | | eswitch | | | | | +------------------------------------------+ 1) pci/0000:05:00.0/0: type eth netdev enp5s0np0 flavour physical switch_id 00154d130d2f 2) pci/0000:05:00.0/10000: type eth netdev enp5s0npf0s0 flavour pci_pf pf 0 subport 0 switch_id 00154d130d2f 3) pci/0000:05:00.0/10001: type eth netdev enp5s0npf0vf0 flavour pci_vf pf 0 vf 0 switch_id 00154d130d2f 4) pci/0000:05:00.0/10001: type eth netdev enp5s0npf0s1 flavour pci_pf pf 0 subport 1 switch_id 00154d130d2f This is basically what you have and I think we are in sync with that. But what about 5,6,7? Should they have devlink port instances too? 5) pci/0000:05:00.0/1: type eth netdev enp5s0f0?? flavour ???? pf 0 subport 0 6) pci/0000:05:10.1/0: type eth netdev enp5s10f0 flavour ???? pf 0 vf 0 7) pci/0000:05:00.0/1: type eth netdev enp5s0f0?? flavour ???? pf 0 subport 1 These are the "peers". I think that there could be flavours "pci_pf" and "pci_vf". Then the "representors" (switch ports) could have flavours "pci_pf_port" and "pci_vf_port" or something like that. User can see right away that is not "PF" of "VF" but rather something "on the other end". Note there is no "switch_id" for these devlink ports that tells the user these devlink ports are not part of any switch. What do you think? >pci/0000:82:00.0/0: type eth netdev p4p1 flavour physical >pci/0000:82:00.0/10000: type eth netdev eth0 flavour pci_pf pf 0 > [...]