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 80A1CC43381 for ; Fri, 1 Mar 2019 07:46:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 50BDC218AE for ; Fri, 1 Mar 2019 07:46: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="Z824pS1G" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732888AbfCAHq4 (ORCPT ); Fri, 1 Mar 2019 02:46:56 -0500 Received: from mail-wr1-f65.google.com ([209.85.221.65]:40679 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732869AbfCAHq4 (ORCPT ); Fri, 1 Mar 2019 02:46:56 -0500 Received: by mail-wr1-f65.google.com with SMTP id q1so24755793wrp.7 for ; Thu, 28 Feb 2019 23:46:54 -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=gF7cEobZeR/oXP7W0kCCF7UgUh1+Iq3Ui9UnysbAYdM=; b=Z824pS1GYNClip9di0YltUvlMbmgpmGOm8k10tu2FyxWpsBCLeoekkMm3jjLA+poep QakaPqXdCDYiOtNs/mDooYbTAUJ1/OVYlkYp9tn8eX96IFEmpwtHtwpRLI2E6SAlYx4p UUpgW1vzhzrMmlXrlK8dnePXj6Ex6TMruBx3L0lbKHcl0/pHYqMs3ZwCv+QT/liA/dKa 0KO1D4odOUgu0xA71GLaPKxu9mAwbG3h54FB8XxFEjk19jHfy263az/0pWRaX8r7klSU /aUPMxNdMoEvH8yeksCJUgU2irDIb7PAzxZMOClWEhQay13/yJ27SMwGKuVr1fhbPL06 S4cA== 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=gF7cEobZeR/oXP7W0kCCF7UgUh1+Iq3Ui9UnysbAYdM=; b=CNIlk42+k3eRRgIvpYdcouhnE6xhO1b5XCaP8I+hMpNK2WwguPUsgOnQI54Wfsfntm fJM1q2AAjPDU/8MIVkOvqa/vAUdvOSJoUOxh/rd2CD2ksoTH6ftF5GetLWFo9Hv/QVJg wi3q32qfGZZkbY7eYhknwE/RDp2O2O8rGQ1Ppx7/KZm6NMOeRl2u2fgXzwLplwEkApp/ UfuKKRiI3/6S83GEha33JP0XsBs3xHSJszDapFZKj4zGwZ8/Gf2cxpILZ/FeJt8CyJT7 XVvd9cDiYDQg1WRsa1v4iNGGC14ux7npdRYdjS239aBjy+LNlgPFzUy4C6tPObhbmG1/ ZRag== X-Gm-Message-State: APjAAAWMB2sfVwtH46ijA5jn33PhD1pRwtdTKHf5vFSDq8UWiicU+HtQ 2v3G2wLWgSk6YvyDLQwZJVQH0g== X-Google-Smtp-Source: APXvYqypKvvpXMlvHmbcNxDSHoyNwOrmdUd3qdzT85T/89CSfEOeoz1WqJJbFjfJLHmsr4FkZqJ8mw== X-Received: by 2002:a05:6000:1185:: with SMTP id g5mr2210934wrx.299.1551426413957; Thu, 28 Feb 2019 23:46:53 -0800 (PST) Received: from localhost (ip-89-177-134-16.net.upcbroadband.cz. [89.177.134.16]) by smtp.gmail.com with ESMTPSA id a74sm6037037wma.22.2019.02.28.23.46.53 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 28 Feb 2019 23:46:53 -0800 (PST) Date: Fri, 1 Mar 2019 08:37:00 +0100 From: Jiri Pirko To: Jakub Kicinski Cc: davem@davemloft.net, oss-drivers@netronome.com, netdev@vger.kernel.org Subject: Re: [PATCH net-next 6/8] devlink: introduce port's peer netdevs Message-ID: <20190301073700.GH2314@nanopsycho> References: <20190226182436.23811-1-jakub.kicinski@netronome.com> <20190226182436.23811-7-jakub.kicinski@netronome.com> <20190227130829.GC2240@nanopsycho> <20190227104742.3897ae1a@cakuba.netronome.com> <20190228090054.GE2324@nanopsycho.orion> <20190228083644.1387fb7a@cakuba.netronome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190228083644.1387fb7a@cakuba.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 Thu, Feb 28, 2019 at 05:36:44PM CET, jakub.kicinski@netronome.com wrote: >On Thu, 28 Feb 2019 10:00:54 +0100, Jiri Pirko wrote: >> Wed, Feb 27, 2019 at 07:47:42PM CET, jakub.kicinski@netronome.com wrote: >> >On Wed, 27 Feb 2019 14:08:29 +0100, Jiri Pirko wrote: >> >> Tue, Feb 26, 2019 at 07:24:34PM CET, jakub.kicinski@netronome.com wrote: >> >> >Devlink ports represent ports of a switch device (or SR-IOV >> >> >NIC which has an embedded switch). In case of SR-IOV when >> >> >PCIe PFs are exposed the PFs which are directly connected >> >> >to the local machine may also spawn PF netdev (much like >> >> >VFs have a port/"repr" and an actual VF netdev). >> >> > >> >> >Allow devlink to expose such linking. There is currently no >> >> >way to find out which netdev corresponds to which PF. >> >> > >> >> >Example: >> >> > >> >> >$ devlink port >> >> >pci/0000:82:00.0/0: type eth netdev p4p1 flavour physical >> >> >pci/0000:82:00.0/10000: type eth netdev eth1 flavour pci_pf pf 0 peer_netdev enp130s0 >> >> >pci/0000:82:00.0/10001: type eth netdev eth0 flavour pci_vf pf 0 vf 0 >> >> >pci/0000:82:00.0/10002: type eth netdev eth2 flavour pci_vf pf 0 vf 1 >> >> >> >> Peer as the other side of a "virtual cable". For PF, that is probably >> >> sufficient. But I think what a "peer of devlink port" should be "a >> >> devlink port". >> > >> >Maybe I'm not clear on what devlink port is - to me its a port of the >> >ASIC. The notion of devlink port connected to devlink port seems >> >to counter such definition :S >> >> "port of the ASIC" in a sence of "eswitch ports"? > >Yes. > >> >I do not think that every netdev should have a devlink port associated. >> > >> >> Not sure about VF. >> >> >> >> Consider a simple problem of setting up a VF mac address. In legacy, you >> >> do it like this: >> >> $ ip link set eth2 vf 1 mac 00:52:44:11:22:33 >> >> However, in new model, you so far cannot do that. >> > >> >Why? >> > >> >$ devlink port set pci/0000:82:00.0/10001 peer_eth_addr 00:52:44:11:22:33 >> >> Yeah. That is not yet implemented. I agree it is most straightforward. >> The question is, is it fine to have set of: >> peer_eth_addr >> peer_mtu >> peer_something_else >> Or rather to have some object to pin this on. Something like: >> >> $ devlink port peer set pci/0000:82:00.0/10001 eth_addr 00:52:44:11:22:33 > >I do like the object one better, would this mean I should restructure >the peer stuff somehow (netlink attribute structure)? Well we can introduce separate commands: DEVLINK_CMD_PORT_PEER_GET DEVLINK_CMD_PORT_PEER_SET For "set" part, this would work nice. However for the "get" part, we would have to call both DEVLINK_CMD_PORT_GET and DEVLINK_CMD_PORT_PEER_GET. So probably better to add a nest attr: DEVLINK_ATTR_PORT_PEER and have attrs like: DEVLINK_ATTR_PORT_PEER_HW_ADDR (does not have to be always eth, right?) DEVLINK_ATTR_PORT_PEER_TYPE (DEVLINK_PORT_TYPE_NOTSET/DEVLINK_PORT_TYPE_ETH/DEVLINK_PORT_TYPE_IB) DEVLINK_ATTR_PORT_PEER_NETDEV_IFINDEX DEVLINK_ATTR_PORT_PEER_NETDEV_NAME DEVLINK_ATTR_PORT_PEER_NETDEV_IBDEV_NAME in the nest. The userspace part can stay as I described previously: $ devlink port peer set pci/0000:82:00.0/10001 hw_addr 00:52:44:11:22:33 Not sure about "port show" output. In json, the "peer" things should be under "peer" dictionary. > >The MTU stuff is tricky, perhaps best left for its own series ;) > >> >It's more of a neighbour info situation than a local port situation. >> > >> >> What I was thinking about was some "dummy peer" which would be on the >> >> host. Not sure if only as a "dummy peer devlink port" or even as some >> >> sort of "dummy netdev". >> >> >> >> One way or another, it would provide the user some info about which VF >> >> representor is connected to which VF in VM (mac mapping). >> > >> >Ack, but isn't the MAC setting is the only thing we're missing from >> >"switchdev SR-IOV"? Would the "dummy netdev" be used for anything >> >else? I would rather not introduce new netdev just to do that >> >> Agreed. It was just a wild idea :) > >:) > >> >(that'd be a third for that port.)