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 CF610C43381 for ; Wed, 27 Feb 2019 18:47:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8BB412184A for ; Wed, 27 Feb 2019 18:47:50 +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="sZ0mfiRW" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729986AbfB0Srt (ORCPT ); Wed, 27 Feb 2019 13:47:49 -0500 Received: from mail-qk1-f196.google.com ([209.85.222.196]:33576 "EHLO mail-qk1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727488AbfB0Srt (ORCPT ); Wed, 27 Feb 2019 13:47:49 -0500 Received: by mail-qk1-f196.google.com with SMTP id x9so10530704qkf.0 for ; Wed, 27 Feb 2019 10:47:48 -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=OGOZEjxSop35LnfYva7wJDCdXyMch8O2SBDCpby91j4=; b=sZ0mfiRWuveuF2L7eEVb2aTLSUpleeLlPqY4kECnAW/bfzA6vliZIYXn12GaMUYIdG 38riCFrL+mCyjvG8TinQKY/TSMy7nNQSovRbumdy2qltnG1Q1drPFF74SREQY0WbJ4Pf wAUZPt13Pa8W061okbx0dtbiFAmRWU1VQlqS1ZJamCvkwI5+WrT3XMP7I4SM+vRsz4A3 QGQwRygN4lZcjziqfQEEZ9eNAhKLpob1kwG1RvetlV2B0il54W8PQ5clDq0rxNQvbpzF 7XgRTCApzMBf2/iLO1ss3NYFW0eLpvIqZklszwFTHwBrrvn/nPDIHedFdEAI+4SoOnR5 m5wQ== 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=OGOZEjxSop35LnfYva7wJDCdXyMch8O2SBDCpby91j4=; b=JTwg8IE2vw1qyUXFdSzy2zZk8iO5BDXTTuKIGj8OTMkVji1rytN9D9QSSf2b0eEAVk jUISivZ1MF6GjY7z5eQus2NvQNxrEtUrRRlu8LdRdJN73kupfM2QOwYv+JbW8mxIK2gj 5ka76Osg5vfUUzARSbT3Hw2j7fr2bopzfY/azbEHb5CgC24T7nJlKFEtfQQjS6o/pO5O X+1zZvKoNlGdRFvnr1P/rfPUwCbwqMnrvbWa8FQzpXy7t0dI5Y4uzW8/J62EC3SB3LRl /xTAfGGndL2sGMnv7Ee3QLJMv+av+q2Vqv+LNiekvJWYm9HFERk/Kc7jvlVETxf7SR9x t6KQ== X-Gm-Message-State: AHQUAubKCb0R44hhVID/hoV9McDEGvjXWkd86AnsNofBieJhL2kX3Okl N9A8ZVm92Qlncl9ZjO3tjO4COA== X-Google-Smtp-Source: AHgI3Ibw6YhlhXLMm9bUyMJoyeayRJOvaZXQ8RrL7z3JfIU9nan0WrgJ8lsK3ccVG41+YYzetm2R+A== X-Received: by 2002:a37:6982:: with SMTP id e124mr3449804qkc.50.1551293267912; Wed, 27 Feb 2019 10:47:47 -0800 (PST) Received: from cakuba.netronome.com ([66.60.152.14]) by smtp.gmail.com with ESMTPSA id l31sm11783581qtb.20.2019.02.27.10.47.47 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 27 Feb 2019 10:47:47 -0800 (PST) Date: Wed, 27 Feb 2019 10:47:42 -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: <20190227104742.3897ae1a@cakuba.netronome.com> In-Reply-To: <20190227130829.GC2240@nanopsycho> References: <20190226182436.23811-1-jakub.kicinski@netronome.com> <20190226182436.23811-7-jakub.kicinski@netronome.com> <20190227130829.GC2240@nanopsycho> 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 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 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 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 (that'd be a third for that port.)