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=-1.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS 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 4A7FBC43381 for ; Sat, 16 Mar 2019 01:16:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E9658218AC for ; Sat, 16 Mar 2019 01:16:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="RKNdPmtu" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726465AbfCPBQ2 (ORCPT ); Fri, 15 Mar 2019 21:16:28 -0400 Received: from mail-qk1-f196.google.com ([209.85.222.196]:33838 "EHLO mail-qk1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726218AbfCPBQ2 (ORCPT ); Fri, 15 Mar 2019 21:16:28 -0400 Received: by mail-qk1-f196.google.com with SMTP id n6so6637666qkf.1 for ; Fri, 15 Mar 2019 18:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=vptBl/IdL45ohdaVjCrjEKM5RXp08RiTcfOEi/6rsTs=; b=RKNdPmtut4WpGCFHzNE6KQ/Lt8P4iEnUTjSqjMTCHrBX46/UAFllWpbtAM93ItvDdm 91uS4ceGWXmTWh58fqHSoADhdqlLRoctbHEirexwS9c8fvkcq7zTvvM6XFa5Sys4paX8 xgtr5Klq9uFYnpFerIUAsH4nLTN4aznDj7V+srweN+Ikb9F5j4AzFCYKlQCosVUxTvq/ 24x20zNVRYCGyayUCzP6aA36TGeunHthJVkZAZ/afNRFfMlph+lJd52WdGpyB17SQ85U lkGMc24ejEJLHV97Sa/bc+MIkFmUt+GqtyC/jV8GByqj15U0z4lYi/lKq/cFEu2b3XjU nhUw== 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:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=vptBl/IdL45ohdaVjCrjEKM5RXp08RiTcfOEi/6rsTs=; b=CuTWzr5MqIkq9HWlEFFf2IGKCmkFrlovZw2NGs4sHhcrhqr0+GnctBMupyk/dfrxfo xNkW5Uz9to4wsQ7I8034WWkcwBB1plgeCpsBgjIMSv1p6Vthzv9MtwTVlK9ZPTBOIPDa 6JtP0P8N6SaNvHWgG+lW9tPdwNUgKbX6LwynximdidoXokcwLDkR7pf6k09xc4CitPK4 ZvW6NU5ldmBfqCi28zgM0Dp6jPCnw9m/fkWRh0FaF+kzYunzpYvdNoa18k3OWC5uqK1v ow8YYUVfY8AHLHBi56L6mLdkX50F5z60vxI2GpT9Ppb7MTE4p9B53CsiXx9Vx8QYS3/A smIg== X-Gm-Message-State: APjAAAVyShuPknzviv+t/m7uycmNJjs0zf4JF/B6ueQzg1hmNLjHAwop uwAKQxPX6J9M0uifIGm5BMdl7g== X-Google-Smtp-Source: APXvYqxRKzdkKjPGlIAkv/MCCCtaFeGq+TX8BxnMeq2rlf4XhFTVVe21ox5lpkOvET1nxdvB30lOzw== X-Received: by 2002:ae9:f101:: with SMTP id k1mr5246069qkg.111.1552698986670; Fri, 15 Mar 2019 18:16:26 -0700 (PDT) Received: from cakuba.netronome.com ([66.60.152.14]) by smtp.gmail.com with ESMTPSA id o19sm2405769qkl.65.2019.03.15.18.16.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 15 Mar 2019 18:16:26 -0700 (PDT) Date: Fri, 15 Mar 2019 18:16:20 -0700 From: Jakub Kicinski To: Parav Pandit Cc: Jiri Pirko , "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: <20190315181620.341bd02c@cakuba.netronome.com> In-Reply-To: References: <20190313095555.0f4f92ca@cakuba.attlocal.net> <20190314073840.GA3034@nanopsycho> <20190314150945.031d1b08@cakuba.netronome.com> <20190314163915.24fd2481@cakuba.netronome.com> <4436da3d-4b99-f792-8e77-695d5958794d@intel.com> <20190315200814.GD2305@nanopsycho> <20190315134454.581f47ca@cakuba.netronome.com> Organization: Netronome Systems, Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, 15 Mar 2019 22:12:13 +0000, Parav Pandit wrote: > > On Fri, 15 Mar 2019 21:08:14 +0100, Jiri Pirko wrote: > > > >> IIUC, Jiri/Jakub are proposing creation of 2 devlink objects for > > > >> each port - host facing ports and switch facing ports. This is in > > > >> addition to the netdevs that are created today. > > > > To be clear I'm not in favour of the dual-object proposal. > > > > > >I am not proposing any different. > > > >I am proposing only two changes. > > > >1. control hostport params via referring hostport (not via indirect > > > >peer) > > > > > > Not really possible. If you passthrough VF into VM, the hostport goes > > > along with it. > > > > > > >2. flavour should not be vf/pf, flavour should be hostport, switchport. > > > >Because switch is flat and agnostic of pf/vf/mdev. > > > > > > Not sure. It's good to have this kind of visibility. > > > > Yes, this subthread honestly makes me go from 60% sure to 95% sure we > > shouldn't do the dual object thing :( Seems like Parav is already confused by > > it and suggests host port can exist without switch port :( > > > I am almost sure that I am not confused. > I am clear that hostports should be configured by devlink > instance which has the capability to program it. Right now a devlink port is something that the datapath of an ASIC can address. All flavours we have presently are basically various MACs - physical (front panel ports), DSA - for ASIC interconnects on a multi-ASIC board, CPU - for connecting to a MAC of a NIC. Jiri's flavour proposal was strictly extending the same logic to SR-IOV. Each object addressable within the datapath gets a port. The datapath's ID can be used as port_index. I just reimplemented his patches here and added the subports which I think he wasn't aware of as they are a quirk of old NFP ASICs. Having 3 objects for the same datapath ID is a significant departure from the existing devlink port semantics. > When hostport is in VF, that VF usually won't have privilege > to program it and won't have visibility to eswitch either. If VM has no visibility into the eswitch and no permission to configure things, what use does the object serve? > Why would you like to start with restrictive model of peer view only? "Restrictive model" is one way of putting it. I'd rather say that we are not adding objects which: (a) do not adhere to current semantics; (b) have no distinct function. We can make the "add MAC address" command not use the word peer: devlink port addr_pool add pci/0000:05:00.0/10003 type eth 00:11:22:33:44:55 devlink port addr_pool del pci/0000:05:00.0/10003 type eth 00:11:22:33:44:55 if the "peer" doesn't sit right. > Hostports exist for infiniband HCA without switchport. > We should be able to manage hostport objects without creating fake eswitch sw object. It sounds like the RDMA subsystem is lacking a model to represent all its objects, but that's RDMA's problem to solve.. In netdev world we have netdevs for ports which a used for bulk of the configuration, most importantly - forwarding. > Jakub, > Can you please point to some example other than veth-pair where you > configure host param (such as mac address) through a switch? Existing "legacy" SR-IOV NDOs. > An existing example will help me to map it to devlink eswitch proposal. > If we go peer programming route, what are your thoughts on > how should we program infiniband hostports which doesn't have peer ports? Again, you may be trying to fix RDMA's lack of control objects, which may be better fixed elsewhere..