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 4215CC43381 for ; Sat, 2 Mar 2019 10:23:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F204F20838 for ; Sat, 2 Mar 2019 10:23:32 +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="qaBREu+J" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726357AbfCBKXb (ORCPT ); Sat, 2 Mar 2019 05:23:31 -0500 Received: from mail-wr1-f67.google.com ([209.85.221.67]:33516 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725986AbfCBKXb (ORCPT ); Sat, 2 Mar 2019 05:23:31 -0500 Received: by mail-wr1-f67.google.com with SMTP id i12so434881wrw.0 for ; Sat, 02 Mar 2019 02:23:30 -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=ebbt/NxI9eSfFUUPU4WD80SdTqE4MI1iWVeTWEMMJuA=; b=qaBREu+Jsz4xyap/6trog15P4RvXu/vNIN7AhNzFPewB+ui7segjXWvyiqct82SHlr hRcpWZY00R4QvM6UhmlQ7lN7e+ccLMlhWEFYEvDIODdj2RW1e4Z7Vs/aBX+uqA+W41cB DE022woloPif9WEL0fRC5ttBMLZJt+kidJukIFEyqNJ/IdfIeiFw5wB6tBl3pNklZrud wea2xRyhBwtr6piADEea2rOBIv6+NJ32VrXPk01TgZZsk59mBXeoDLz2JhusIB9F1Qc5 MTOJiKv/GBTpi1Rn6swFu5mn+puksIlfLtBBZEvgkzW4dZ7cl4Lz0tn6IaDhfSzowQ4c SfBQ== 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=ebbt/NxI9eSfFUUPU4WD80SdTqE4MI1iWVeTWEMMJuA=; b=WKUNqo+IKNTW0HFnBIQa1l+rncy3b5coTxWsrTrW6XnlP/J8EWEQJjhT2blf2QlgVT 8Xjta7i26MEYDvgdCjLM7to+E4IKlM4WJ7D6Qgxq1qCZU7sHi9wVnRG/IB6p3q2Nqb2R rM3BdH46Groly21Sme+kg+2vnSDN1WEnYmc3OoszTahR2N9NR1NTXgIza08lz/qt3tda VLPMmtYEhO4Vqbssh7UmQaz0s1rv1EYG8nV0E0yhAV7xAiHnAXVFvSyofWl8Wgd5RW1J iO9ZHY0KFjnLZwT6YnP06sA2pVERzIHJqpoZBKNM9tppOi3oP0PzR4jgFy0g8j2qFgHk C1Rg== X-Gm-Message-State: APjAAAUWMo+jweau6iRUu6FgKcI9trp5XOZO1sdi8biKaOGj9o2Q/jKz kTy/rFoThLAOifOiblYBVaniYQcxWa6Nxw== X-Google-Smtp-Source: APXvYqxmRd59EcQRnh3Hsia/w0Yf5zavqQJFjrxtduJ39oqPrulRgEpxAhhECpVqMbZOIJFHpqfYPw== X-Received: by 2002:adf:f5d0:: with SMTP id k16mr6131148wrp.325.1551522209569; Sat, 02 Mar 2019 02:23:29 -0800 (PST) Received: from localhost (ip-89-177-134-16.net.upcbroadband.cz. [89.177.134.16]) by smtp.gmail.com with ESMTPSA id s5sm2253924wra.77.2019.03.02.02.23.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 02 Mar 2019 02:23:29 -0800 (PST) Date: Sat, 2 Mar 2019 11:13:37 +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 0/7] devlink: expose PF and VF representors as ports Message-ID: <20190302101337.GR2314@nanopsycho> References: <20190301180453.17778-1-jakub.kicinski@netronome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190301180453.17778-1-jakub.kicinski@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 Fri, Mar 01, 2019 at 07:04:46PM CET, jakub.kicinski@netronome.com wrote: >Hi! > >This series is a long overdue follow up to Jiri's work on providing >a common .ndo_phys_port_name implementation based on devlink ports. > >First devlink port flavours for PF and VF ports are added, and >registered by the NFP. Port numbers and split info are reserved >for physical and DSA ports. For PCIe ports we add pf/vf identifiers. >Note that devices may have more than one PF, including multi host >scenarios where not all pfs are connected to the same host. > >The port_index is slightly tricky to figure out, we use a bit of >math to create unique IDs for ports. > >Next subports for PCIe ports are introduced. This is in case device >has more than one netdev on a physical function (e.g. multi port >SmartNIC). > >With the above features in place we can remove the ndo_phys_port_name >implementation from the NFP and use the standard devlink one for >port netdevs. > >Last but not least a concept of peer netdevs is added. In multi-host >scenarios its currently not possible to figure out which PF is >associated with the local host. Peer device is "the other side >of the wire" for PCIe ports. In case of NFP we only link the PF >netdevs, but it should be possible to also link VF peers after >VF driver probes, if users request it. > >This is the conceptual image of devlink instances: > > HOST A || HOST B > || > PF A | V | V | V | V || PF B | V | V | V > |*F |*F |*F |*F ... || |*F |*F |*F >*port A0 |*port A1 | 0 | 1 | 2 | 3 ||*port B0 |*port B1 | 0 | 1 | 2 > || > PCI Express link || PCI Express link > \ \ \ | | | | | / / / > \ \ \ | | | | | / / / > /\ \______\______\'___|___|__________|_______'____/___/___/__ /\ > || |+PF0s0|+PF0s1 |+VF0|+VF1| ...| |+PF1s0|+PF1s1|+VF0|+VF1| || > i || |------ ------ ----- ---- ----|--- ------ ------ ---- ----| || i >d n H || | <<========== | || d n H >e s O || | ==========>> | || e s O >v t S || | SR-IOV e-switch | || v t S >l a T || | <<========== | || l a T >i n || | ==========>> | || i n >n c A || | ________ _________ ________ | || n c B >k e || | |+Phys 0 |+Phys 1 |+Phys 2 | | || k e > || \---------------------------------------------------------/ || > \/ | | | \/ > | | | > || || > MAC 0 || MAC 1 || MAC 2 > || || > > '+' marks the devlink ports and port (-representor-) netdevs > '*' marks host netdevs (actual VF/PF netdev) As I wrote in the reply to patch 4, I think we need to figure out if we want to model all entities that belong under specific devlink instance/pci address - which I prefer, or we want to have only eswitch ports there. One way or another, I think that it is not good idea to merge this patchset this late, I would prefer to wait for next net-next opening... In the meantime we can sync and make this whole thing crystal clear, for everyone. Thanks!