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 5FDCBC43381 for ; Mon, 11 Mar 2019 09:02:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1ED4F2075C for ; Mon, 11 Mar 2019 09:02:27 +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="ABEevrOR" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726943AbfCKJCZ (ORCPT ); Mon, 11 Mar 2019 05:02:25 -0400 Received: from mail-wm1-f65.google.com ([209.85.128.65]:39092 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725850AbfCKJCZ (ORCPT ); Mon, 11 Mar 2019 05:02:25 -0400 Received: by mail-wm1-f65.google.com with SMTP id z84so3417838wmg.4 for ; Mon, 11 Mar 2019 02:02:23 -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=3lAozT3RmvCnx9mEU21jUzYcTXzqbKTRMXVbuHYzpCM=; b=ABEevrORXHZ0cDwKEUbEM+ZS3jtPd/cQCuqT2g1Zpc+R8ImmWFVPBIa9KXYhmPVv4t D9UjyUcTvZe1YTqSAWXTXPRFh6i2c/atTJ+2ADOWF7bMPFSOCQBHdzNdJ72B+pBBGMc3 uBnbWTs0ulDiSIc9YSAwasL20avB98e/u64Lw5RDnMh/IryKj7UymyarE+UW8/7EsnZI noxJzMGSP0HAiKjmv/Mf0aVS30ebnn0Zhp04i89sEuNtgR6OcKLWuIkfANIzsxZx0Hy5 0Ns0bjUURHaRpv96mMeUnyT6u+Akw1FM8UcnFmdQUSAaoNHvNPwkmKfncQc30S89eiCk QG+w== 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=3lAozT3RmvCnx9mEU21jUzYcTXzqbKTRMXVbuHYzpCM=; b=izGh/9cQzMWLcT5TlH5CxAdlbv9QSQRDXmfj2LaRLzIqBdWzsISvELaQwuz49zjVGq 6mnpSc7pL/qRV3L6SaEX8vGCXSOHR/sEehfyB3yQFfrN/F/3PTQFhGeMu+9nZ452o0j3 ZNNDks8bD6WpVnCrhbtdPyaHzExgmbfR6gMPLmwsYRcJF0ByjhA0rWXO6Tv18XNRUrvH BXJLMqBCXFpEDsAuj/q5Lox0fpVMJkNooicfH97Er8/by/osRcAc15ajR8OdP7YIb5gu uumBnsnrmxxnir9eUNu7MUpEFACjGpLcTM88xb6bB5Ckk+zggqTO3eWUe9t40gS18R8N 63gw== X-Gm-Message-State: APjAAAWByeDrarj9BCJsWdXXwKcjzMPTLr2wpeIbPIohhGH/ww2RzBbR bYCDKXOWkeYjcI2Wkchowo1ZZg== X-Google-Smtp-Source: APXvYqxtgPP6FYHCedVkiYXneXg651RWxeKlbIhuYbhlU+aZDxp+2TZ3kGPsWGpnkzsu5w2X3cosBQ== X-Received: by 2002:a7b:cb04:: with SMTP id u4mr17628859wmj.18.1552294943046; Mon, 11 Mar 2019 02:02:23 -0700 (PDT) Received: from localhost (mail.chocen-mesto.cz. [85.163.43.2]) by smtp.gmail.com with ESMTPSA id t3sm28872579wmc.20.2019.03.11.02.02.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 11 Mar 2019 02:02:22 -0700 (PDT) Date: Mon, 11 Mar 2019 09:52:04 +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: <20190311085204.GA2194@nanopsycho> References: <20190304075609.GV2314@nanopsycho> <20190304163302.7e40219e@cakuba.netronome.com> <20190305110601.GC2314@nanopsycho> <20190305091534.36200de6@cakuba.hsd1.ca.comcast.net> <20190306122037.GB2819@nanopsycho> <20190306095638.7c028bdd@cakuba.hsd1.ca.comcast.net> <20190307094816.GA2190@nanopsycho> <20190307185202.2db37490@cakuba.hsd1.ca.comcast.net> <20190308145421.GA2888@nanopsycho.orion> <20190308110943.2ee42bc0@cakuba.hsd1.ca.comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190308110943.2ee42bc0@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 Fri, Mar 08, 2019 at 08:09:43PM CET, jakub.kicinski@netronome.com wrote: >On Fri, 8 Mar 2019 15:54:21 +0100, Jiri Pirko wrote: >> Fri, Mar 08, 2019 at 03:52:02AM CET, jakub.kicinski@netronome.com wrote: >> >On Thu, 7 Mar 2019 10:48:16 +0100, Jiri Pirko wrote: >> >> Wed, Mar 06, 2019 at 06:56:38PM CET, jakub.kicinski@netronome.com wrote: >> >> >On Wed, 6 Mar 2019 13:20:37 +0100, Jiri Pirko wrote: >> >> >For creating subdevices, I don't think the handle should ever be port. >> >> >We create new ports on a devlink instance, and configure its forwarding >> >> >> >> Okay I agree. Something like: >> >> $ devlink port add pci/0000:00:10.0 ..... >> >> >> >> It's a bit confusing because "set" accepts port handle (like >> >> pci/0000:00:10.0/1). Probably better would be: >> >> $ devlink dev port add pci/0000:00:10.0 ..... >> >> >> >> >with offloads of well established Linux SW constructs. New devices are >> >> >not logically associated with other ports (see how in my patches there >> >> >are 2 "subports" but no main port on that PF - a split not a hierarchy). >> >> >> >> Right, basically you have 2 equal objects. Makes sense. >> >> >> >> >How we want to model forwarding inside a VM (who configures the >> >> >underlying switching) remains unclear. >> >> >> >> I don't understand. Could you elaborate a bit? >> > >> >If VF in a VM gets a partitioning request does the new port pop up on >> >the hypervisor? With a port netdev? >> >> Switchport in hypervizor with correct switchid attribute, hostport in >> vm. Makes sense? > >If the switchport is in the hypervisor then only the hypervisor can >control switching/forwarding, correct? Correct. > >The primary use case for partitioning within a VM (of a VF) would be >containers (and DPDK)? Makes sense. > >SR-IOV makes things harder. Splitting a PF is reasonably easy to grasp. >I'm trying to get a sense of is how would we control an SR-IOV >environment as a whole. You mean orchestration? I originally planned to implement sriov orchestration api in devlink too. > >> >Does the VF also create a port object as well as host port object? >> > >> >That question is probably independent of host port discussion. >