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 2A531C43381 for ; Wed, 6 Mar 2019 12:30:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EB09B2064A for ; Wed, 6 Mar 2019 12:30:47 +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="la5+WPlw" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730126AbfCFMaq (ORCPT ); Wed, 6 Mar 2019 07:30:46 -0500 Received: from mail-wm1-f68.google.com ([209.85.128.68]:51265 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729247AbfCFMaq (ORCPT ); Wed, 6 Mar 2019 07:30:46 -0500 Received: by mail-wm1-f68.google.com with SMTP id n19so5732912wmi.1 for ; Wed, 06 Mar 2019 04:30:45 -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=fHI2PL52+c+n0AQbkNx/q3jEIbrFNJeiw6eYX+YghTs=; b=la5+WPlwWiBz20ECPcPpYvp4Fj2RGNDFPHVQJdFD10K1zR4+X01kyL+F97ozkY2Ok6 +3YLcsH5fbqVQ8oV/r4AHuoZ1kCJCN2KEG/u9VxBnm4zRhL5O1iZibvcm9UHlnDV6y9F 52cFRsjcpa7NbItebfPPsjcUAO6Sl2u4avNTqX2GtFVSZpw46BsGVo9cyfDJ2AkDK08S FE0W6sL/fmqGunLz2/lD+D0u4AtrumWQa1Lcbrun6QpEXYgr+bCy6Mu5kjCqcn0tGhQs 6dOfwQNsDcVRm/O9HZ3XzrrRATmcbb1g2NzIrQkJ59sSaHwAon8Mu0vdAXe6IVfUExQw 6rGQ== 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=fHI2PL52+c+n0AQbkNx/q3jEIbrFNJeiw6eYX+YghTs=; b=XOwVicwyZ3CjCnunt83quz8lVSX3zfPi4Sq7WzjhUPAmK78iqWs2YvkBgqY1y8d8fi cbKzkTwUCMqBAvfUsgDSj27hZmCAeLX6U/gEZYriyniBCURJ6y2rsGOtEvIhE58rWIIU Gj0+ZU0U4KwlL6f5yksCN57LGpzro69pYYnHgNcKElbY2F1ka6lSLGZDAm1jiSBCCXK3 AJxYjQ5gTUYXgVGeqyPLu3lCuFxeQ9UOntI85LpfGtkw6F4oASpUxGHzASB/ZvF2TNKO PRz5tF2FGJBg6DlGA347nOlSu18RjRWA+AEm2eVXB0sYlEDfd4zZH5sQsyACUBP3hHR0 zpKQ== X-Gm-Message-State: APjAAAUoI5ZeGgFGVearSEratkkfgYyEff1So6hhjOsa9pbv0yMVYxr3 qHFwsXZfPjOWfnaOVLEwLq3Ztw== X-Google-Smtp-Source: APXvYqxLB+SW/RnITFnpcd1PtE9PGF/j8H5Lvl8ikFi/E/qHlLOA+21HvdiYDHO1AZhq7sG2MYb9og== X-Received: by 2002:a7b:c14a:: with SMTP id z10mr1617840wmi.99.1551875444487; Wed, 06 Mar 2019 04:30:44 -0800 (PST) Received: from localhost (mail.chocen-mesto.cz. [85.163.43.2]) by smtp.gmail.com with ESMTPSA id d1sm1038547wrs.13.2019.03.06.04.30.43 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 06 Mar 2019 04:30:43 -0800 (PST) Date: Wed, 6 Mar 2019 13:20:37 +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: <20190306122037.GB2819@nanopsycho> References: <20190301180453.17778-1-jakub.kicinski@netronome.com> <20190301180453.17778-5-jakub.kicinski@netronome.com> <20190302094116.GQ2314@nanopsycho> <20190302114847.733759a1@cakuba.netronome.com> <20190304075609.GV2314@nanopsycho> <20190304163302.7e40219e@cakuba.netronome.com> <20190305110601.GC2314@nanopsycho> <20190305091534.36200de6@cakuba.hsd1.ca.comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190305091534.36200de6@cakuba.hsd1.ca.comcast.net> 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 Tue, Mar 05, 2019 at 06:15:34PM CET, jakub.kicinski@netronome.com wrote: >On Tue, 5 Mar 2019 12:06:01 +0100, Jiri Pirko wrote: >> >> >as ports. Can we invent a new command (say "partition"?) that'd take >> >> >the bus info where the partition is to be spawned? >> >> >> >> Got it. But the question is how different this object would be from the >> >> existing "port" we have today. >> > >> >They'd be where "the other side of a PCI link" is represented, >> >restricting ports to only ASIC's forwarding plane ports. >> >> Basically a "host port", right? It can still be the same port object, >> only with different flavour and attributes. So we would have: >> >> 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 >> peer pci/0000:05:00.0/1 >> 3) pci/0000:05:00.0/10001: type eth netdev enp5s0npf0vf0 >> flavour pci_vf pf 0 vf 0 >> switch_id 00154d130d2f >> peer pci/0000:05:10.1/0 >> 4) pci/0000:05:00.0/10001: type eth netdev enp5s0npf0s1 >> flavour pci_pf pf 0 subport 1 >> switch_id 00154d130d2f >> peer pci/0000:05:00.0/2 >> 5) pci/0000:05:00.0/1: type eth netdev enp5s0f0?? >> flavour host <---------------- >> peer pci/0000:05:00.0/10000 >> 6) pci/0000:05:10.1/0: type eth netdev enp5s10f0 >> flavour host <---------------- >> peer pci/0000:05:00.0/10001 >> 7) pci/0000:05:00.0/2: type eth netdev enp5s0f0?? >> flavour host <---------------- >> peer pci/0000:05:00.0/10001 >> >> I think it looks quite clear, it gives complete topology view. > >Okay, I have some of questions :) > >What do we use for port_index? That is just a number totally in control of the driver. Driver can assign it in any way. > >What are the operations one can perform on "host ports"? That is a good question. I would start with *none* and extend it upon needs. > >If we have PCI parameters, do they get set on the ASIC side of the port >or the host side of the port? Could you give me an example? But I believe that on switch-port side. > >How do those behave when device is passed to VM? In case of VF? VF will have separate devlink instance (separate handle, probably "aliased" to the PF handle). So it would disappear from baremetal and appear in VM: $ devlink dev pci/0000:00:10.0 $ devlink dev port pci/0000:00:10.1/0: type eth netdev enp5s10f0 flavour host That's it for the VM. There's no linkage (peer, alias) between this and the instances on baremetal. > >You have a VF devlink instance there - what ports does it show? See above. > >How do those look when the PF is connected to another host? Do they >get spawned at all? What do you mean by "PF is connected to another host"? > >Will this not be confusing to DSA folks who have a CPU port? Why do you think so?