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 54D9CC43381 for ; Fri, 29 Mar 2019 21:21:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0AC032184C for ; Fri, 29 Mar 2019 21:21:59 +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="wnvoz3Fz" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729982AbfC2VV6 (ORCPT ); Fri, 29 Mar 2019 17:21:58 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:33983 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729484AbfC2VV5 (ORCPT ); Fri, 29 Mar 2019 17:21:57 -0400 Received: by mail-wr1-f68.google.com with SMTP id p10so4265040wrq.1 for ; Fri, 29 Mar 2019 14:21:56 -0700 (PDT) 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=sSKxUFOfEvuBYQYktcjkD5t3Pymex0C3Ee+sFD0gBO8=; b=wnvoz3FznKC/R0g/+/PjczNcyH9d4K0z3UDX3ZJfuSSTWXB5FBdqsW+GViFonsICc4 d+ViOizit+1IBuVdA6JYTqZf9dfMdjx7xlSuNK2D4ENGiUV9Mjqgqt6ZxztAI7lTa/WJ 67xYkSUls4+qb7DoKovEJcAjRMTX1+LhyDatAHdUZxOw8BtRWRPCx4eXYlcCYK8ASFpP TOmv3Y99sOb0HAPGuHBo2vHKaOkTrwlwDyfOYQDLbBhwB6pHg3cTY9ApL41LNIC3NHY9 +4KiobPJSnW6ohaRIVSxRCdkZ5DDHwMBAr9z89agNmU8Oxo0NneIGVbz1PQoDLEH7PFV yQcw== 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=sSKxUFOfEvuBYQYktcjkD5t3Pymex0C3Ee+sFD0gBO8=; b=brlI3wIAiWUdZmBtAWK+Y/4zwcZOvSNUGnOTcu+GBkryHt2e3IfKmTJt4Pt4YB3UVU BcHxvupJPhOEcoYde8JELcd7ggYHzLMggpzlpmQviEBtcX9LYEgXjtcJrrb7hK+1kb8G if+TXgmBrHhPs56aECYGrC+NhFK8L50M5GKfDyPVMGMOA/OXQ+MLkvAGpcOkP0tyKHDK OM8ommrKcBqD+sluCbEw9D/GUKzJm0KacbUuorth1cJdRr21F5wgvbVbwxn9cAP2NwNL l/+KRagWoyqFtJ1WPY/VenMtjd4gWK2/ORjkC3l3c9G7VrKzCzsrap4nHxMyBzQc7E/3 5PTg== X-Gm-Message-State: APjAAAVVVsU1Ph26y5ubLWU+RFxQIDos8MAfonQZsBWaH3lPoYDs5N0V 52x2FaSJNHH/PRR46Le7YJSgtw== X-Google-Smtp-Source: APXvYqy0WkmYbDr1CDtwLmYDiiX3Vylohog+o0NTEJUAodX28wUoMhNlFfL+GNoiQnwXGbsmGhVpPw== X-Received: by 2002:a5d:68c6:: with SMTP id p6mr34339718wrw.321.1553894515737; Fri, 29 Mar 2019 14:21:55 -0700 (PDT) Received: from localhost (ip-94-113-223-73.net.upcbroadband.cz. [94.113.223.73]) by smtp.gmail.com with ESMTPSA id u17sm2455494wmj.1.2019.03.29.14.21.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 29 Mar 2019 14:21:54 -0700 (PDT) Date: Fri, 29 Mar 2019 22:21:53 +0100 From: Jiri Pirko To: Jakub Kicinski Cc: netdev@vger.kernel.org, davem@davemloft.net, mlxsw@mellanox.com, idosch@mellanox.com, f.fainelli@gmail.com, andrew@lunn.ch, vivien.didelot@gmail.com, michael.chan@broadcom.com, ogerlitz@mellanox.com Subject: Re: [patch net-next 00/12] net: expose switch ID via devlink Message-ID: <20190329212153.GA14297@nanopsycho> References: <20190328211254.1894-1-jiri@resnulli.us> <20190328144002.245c9eef@cakuba.netronome.com> <20190329064905.GS14297@nanopsycho> <20190329115926.5c16d2fd@cakuba.netronome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190329115926.5c16d2fd@cakuba.netronome.com> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Fri, Mar 29, 2019 at 07:59:26PM CET, jakub.kicinski@netronome.com wrote: >On Fri, 29 Mar 2019 07:49:05 +0100, Jiri Pirko wrote: >> Thu, Mar 28, 2019 at 10:40:02PM CET, jakub.kicinski@netronome.com wrote: >> >On Thu, 28 Mar 2019 22:12:42 +0100, Jiri Pirko wrote: >> >> From: Jiri Pirko >> >> >> >> To provide visibility of the ports, this patchset exposes switch ID >> >> for devlink ports, which are part of a switch. The rest of the ports >> >> if any (in case of sr-iov for example) do not set switch ID. >> > >> >I don't feel good about this patch set. There is no visibility >> >provided here. Should the port flavour should be a sufficient >> >> 1) this patch is mainly about avoiding need to define the ndo and moving >> the switch id definition to devlink port attr. > >Sure, that you could achieve by putting the data in the netdevice >structure as well.. > >What is the guiding principle here? I'm trying to argue for leaving >forwarding-related info in netdev code, and only have HW control in >devlink. I just don't see switch id being useful at devlink level in >any way. Well we have switchib driver which does not have any netdevice and still the ports are part of a switch. In other words, this is not ethernet-specific attribute, therefore devlink is the right fit. > >> 2) along with that, switch id is added as attribute. It tells the user >> that some devlink port is part of a switch with certain id. If port >> is not part of a switch (like upcoming hostport, cpu, dsa, etc), >> switch id is not set on that port > >If the flavour already gives that information, why crowd the attributes >for ports with switch id? Hmm, we'll have multiple non-switch port flavours and once your vf/pf patchset hits the tree we'll have multipkle switch port flavours. So makes sense to have switch id. Also, you can have multiple switches within one asic. > >> >indication of whether netdev associated with that port can be >> >switched to or not? CPU, DSA, and Host flavours can't be switched >> >to. And the switchid can be an attribute of the devlink instance, >> >if we want to expose it via devlink. >> >> One devlink instance can have multiple switch ids in use as it may >> contain multiple switches. Take mlx5 as an instance. Currently every PF >> creates a separate devlink instance, however there are some features >> shared. In this example, with proposed idea of aliasing, there would be >> one devlink instance aliased between these 2 pf inctances, with 2 >> eswitches and 2 sets of switch ports each belonging to an eswitch - >> distinguished by switch id. > >Out of curiosity, what are the shared features? It seems mlx5 drives >a lot of our API design, it'd be good if the community had a better >understanding of it. I have to gather that info. Not so many things are shared. There is one extra switch to mix 2 pfs together. I know about some IB features that also mix 2 pfs. > >The situation with pipelined devices is somewhat murky. Didn't Or add >some from of PCIe-side looped queue to forward between PFs? I have no clue. Ccing Or. Or? > >Presumably DSA would lean the opposite way with multiple ASICs >reporting the same ID? Yes, sounds right.