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 44D34C43381 for ; Wed, 27 Feb 2019 12:37:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 102AA2133D for ; Wed, 27 Feb 2019 12:37:58 +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="NuQ/Ejmi" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730201AbfB0Mh4 (ORCPT ); Wed, 27 Feb 2019 07:37:56 -0500 Received: from mail-wr1-f66.google.com ([209.85.221.66]:32907 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730196AbfB0Mh4 (ORCPT ); Wed, 27 Feb 2019 07:37:56 -0500 Received: by mail-wr1-f66.google.com with SMTP id i12so17812686wrw.0 for ; Wed, 27 Feb 2019 04:37:55 -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=k+tpqADKMOz0hkNz7/q6RHS90Gmuc8E+HVZ6feXlbvo=; b=NuQ/EjmiIRAkGKZ/fSvPoz+7ZETQaUjm31kNRibdNkhB12Jybq0w7IDcXcZKuRYiW7 iYcCmXPVjKfp9a+jbmfBWjbJxa2hX4Dr9BQxx6hEPiaPTOno/fA/pAQldOGfjHzAWGZc YYnMzkKOmrvZe3mohiB8O4GiQihwJG27zfNfTm8zScY/heBww7HzGh75p0+tx/+ECUL9 C4LVG2rRGj245Vw7I+24Y3dT2jIzENWWux/zadsnUNryEm5IkQlTCIbhMQVzLV2UrX/r N9Eo0uJL23hr2mVyK9HRsJLctFlnANLYqomRavr5BcX3BEVMzCopAvXTL9rc1Wc2pkeP kfqw== 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=k+tpqADKMOz0hkNz7/q6RHS90Gmuc8E+HVZ6feXlbvo=; b=T/K30WYuEHCq9lSGSG2Z2t27FmklMbaTSYCwstKWCZM2M4VjuzyMOcMgQ+/PiVdxWb x6oAdDKqqLox4TZpHjMhKLJMVeaflT47N7ogpZdgNI8csX8xIAUcne0z/Q+r9EsmdhGE rZzqB86oqj27c8kMvPFK7dcJPciXz7DNCC+SpmBWlJU9XOqWF8vIFZFV+7e8e2PiVA0P aOcna3InxjgQgRbDIL/hE/+YyAU0VUywHAAREtYZtFy1aBGbBV0OW2bxfoBUwixqiiS1 w1Dy143kNQkjoZsEzohXxyRCfoPpfqFZuwIy5NZ1BeShDLTACwCbiGq73/lsCOU3uwpR +9qQ== X-Gm-Message-State: APjAAAXzH1HBXJHy4H6OmczLSABofvCv5Ph9MWiMtHil+2WnXtEyqwt2 +SZogiFCZtdKc1J/fNlbUPAqzQ== X-Google-Smtp-Source: APXvYqziuPmKROwBC8gtx6CB4ljoaoVzDNgHQMkDNrDiDH7IvexD864kW4Rz1LpTBuiCVjenDtJrRw== X-Received: by 2002:adf:ed11:: with SMTP id a17mr2268284wro.283.1551271074688; Wed, 27 Feb 2019 04:37:54 -0800 (PST) Received: from localhost (mail.chocen-mesto.cz. [85.163.43.2]) by smtp.gmail.com with ESMTPSA id s3sm20785796wrt.81.2019.02.27.04.37.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 27 Feb 2019 04:37:54 -0800 (PST) Date: Wed, 27 Feb 2019 13:37:53 +0100 From: Jiri Pirko To: Jakub Kicinski Cc: davem@davemloft.net, oss-drivers@netronome.com, netdev@vger.kernel.org, parav@mellanox.com, jgg@mellanox.com Subject: Re: [PATCH net-next 4/8] devlink: allow subports on devlink PCI ports Message-ID: <20190227123753.GB2240@nanopsycho> References: <20190226182436.23811-1-jakub.kicinski@netronome.com> <20190226182436.23811-5-jakub.kicinski@netronome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190226182436.23811-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 Tue, Feb 26, 2019 at 07:24:32PM 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. > We've been discussing the problem of subport (we call it "subfunction" or "SF") for some time internally. Turned out, this is probably harder task to model. Please prove me wrong. The nature of VF makes it a logically separate entity. It has a separate PCI address, it should therefore have a separate devlink instance. You can pass it through to VM, then the same devlink instance should be created inside the VM and disappear from the host. SF (or subport) feels similar to that. Basically it is exactly the same thing as VF, only does reside under PF PCI function. That is why I think, for sake of consistency, it should have a separate devlink entity as well. The problem is correct sysfs modelling and devlink handle derived from that. Parav is working on a simple soft bus for this purpose called "subbus". There is a RFC floating around on Mellanox internal mailing list, looks like it is time to send it upstream. Then each PF driver which have SFs would register subbus devices according to SFs/subports and they would be properly handled by bus probe, devlink and devlink port and netdev instances created. Ccing Parav and Jason.