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 4BC98C43381 for ; Thu, 28 Feb 2019 16:36:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 19C71218AE for ; Thu, 28 Feb 2019 16:36:54 +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="FddRidXD" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731774AbfB1Qgx (ORCPT ); Thu, 28 Feb 2019 11:36:53 -0500 Received: from mail-qt1-f194.google.com ([209.85.160.194]:42553 "EHLO mail-qt1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726027AbfB1Qgw (ORCPT ); Thu, 28 Feb 2019 11:36:52 -0500 Received: by mail-qt1-f194.google.com with SMTP id u7so15004536qtg.9 for ; Thu, 28 Feb 2019 08:36:51 -0800 (PST) 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=6gcvoHmA20Lcxsz/dQqeySpdrZDEC+n2+oKdzh/0+bY=; b=FddRidXD2l8KTQi1VK32V6otaJNHrvEvcVqkTROKgZQL4swkLp0Z6VPHskGUDKU6YH kFAK+Qcw+uBLWwCrmCqvV7WQjq80PvJvDpLazYpXwr+kARWgcWNqMVH8S7OK/0qDbz/O 1KfzZsVyI0dpoPZZwIZqYewKoEdq/+NnRFLgnLt8rN1A/hos5XatkpKmYpLb7HOBRyvF qU97yoYX93fNEVKfzR48LZEtKDldRKPz+F7bc2+U+IdM6iLSe4Z9zLaF7BaJxqk/sT22 bJGfS3lIfA4+1CByrVbnzLHVETe8qj3mScTr4ZqSLEqPXtk+VZLQ2zk5iIYnKfsSFzhs 0z4g== 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=6gcvoHmA20Lcxsz/dQqeySpdrZDEC+n2+oKdzh/0+bY=; b=o/hkgFJkeR9dfl8SZajWFQ54zDYskIufoOBSO2e7OZGr+PkvCuZeajL9tfh1JBpEGN cI+VLrzOz9DVUpKQQluaMDuYSioIclARQMYioQ4qSAiBFHnvIgVWC8Ke6imab9ivgKr6 rzJUjMegVuSkbyPxUZ0v82hl4G6/c6Odb/o3Tv+Ddk774BDIIRVw3fvuFtKMX+ZB6PjS ZlWeIi5Z1M7xGsBAxOpgDJDdmSesNo5EkLqCVaRAJgiB35PPBopLOVmbBrfsMySgXALN nO0AXRMYBEg7d70xcBuGAZSQfoaJd6AhSk6UjnXv4+YNqh0Y0Wrb7OCHe9IPHdx/P6qG TGzg== X-Gm-Message-State: APjAAAWLG9I/Wf2MgS0MUqVIa2H3cGIztLztdhCwSMGijNmpzWJSfI/R m0ln5jyLsj2YiQbb65x4YWmHgQ== X-Google-Smtp-Source: APXvYqyAzZ3qAgyBmMc0iIjDP5sabF52Ymrz1nlit9JtXG/xMOXAPH7I0+X/MajMteqkabEgRKHYOw== X-Received: by 2002:a0c:963d:: with SMTP id 58mr7133222qvx.25.1551371811156; Thu, 28 Feb 2019 08:36:51 -0800 (PST) Received: from cakuba.netronome.com ([66.60.152.14]) by smtp.gmail.com with ESMTPSA id a3sm14254290qta.21.2019.02.28.08.36.50 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 28 Feb 2019 08:36:51 -0800 (PST) Date: Thu, 28 Feb 2019 08:36:44 -0800 From: Jakub Kicinski To: Jiri Pirko 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: <20190228083644.1387fb7a@cakuba.netronome.com> In-Reply-To: <20190228090054.GE2324@nanopsycho.orion> 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> 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 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)? 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.)