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 9769BC43381 for ; Sat, 30 Mar 2019 07:35:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 46D05218A6 for ; Sat, 30 Mar 2019 07:35: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="ZOGa1K6y" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726569AbfC3Hfb (ORCPT ); Sat, 30 Mar 2019 03:35:31 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:42568 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726378AbfC3Hfa (ORCPT ); Sat, 30 Mar 2019 03:35:30 -0400 Received: by mail-wr1-f65.google.com with SMTP id g3so5249980wrx.9 for ; Sat, 30 Mar 2019 00:35:29 -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=3Muf+2g/HLcp8c1VAyW33FULY4ec+BV6Og8mkRODaKg=; b=ZOGa1K6y42OZyMyOb6qhzpkDs96pvrEhWKc3tPyZpPUZG0FsPCnep3gqcnsZLVWNqF jWMnRdRfVpP/w8ZzCXAxeTPkX3kyirhX2KyxL7zdWeiypGHn0AITapzW/8G1Z6WW5EKS 4Wk5ZBRi4sL0ISDZQ7RcS8EzqrSntv6a2XaPNI+uXKFW1rvTmX4tvzBODAoFJHKgFx6K swtzrAQ1io8npBt25jrDzpoFC6VNnZkt2zoAgC76K60BvGZ+H0bXumwW4pNhC7s0RcnD x1Mn5A6FH/Jti+xnBdvuZoeH+kS7dno59DtJqQknrF+r0TtHiD/so4oQ2YJC40LqFvVZ T/HQ== 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=3Muf+2g/HLcp8c1VAyW33FULY4ec+BV6Og8mkRODaKg=; b=j+cOMYAz6HeBHboz+Btdfv0LV/nB9mbUwlVKYRwabPccpadC4JVsBgQ+jPWU1lxokB fV0XLyIRQVT4n66fcFz53GFk6+hRshQE2lg0FALZucIEKFr2ToUhATvNLR+dHQsr9l1a x9l9dlx+8a5OFEZekCUe/a/XFe7rWBlwcJofyi81wosvGXCc7bgW7hsyXiR/kiErPehQ hW4d8rnuEC+wA2KYZfHVhSoeOd6R2a4Tkz7lvjZnRLuhpud7ul1sopHwWmu5xKvylC0t z0qtOwMJi72hP+oGY2x1NEESIJg8IofpRaO/hZt539oMSg9euuZNjPfW9kYOWI09sda+ Bxow== X-Gm-Message-State: APjAAAU8/dbyovJDDZubMA1ns0KVp/QSnv/o0aH302dXUc5+9aIHUnAc ACQ/ls0F58UxEQO7aMZ7PMHKuw== X-Google-Smtp-Source: APXvYqxYEXLKkFR05Dl0eymrRwSCxtJDcsvrmA1WWGMgAaOgv3mY4fxpJ3vUmC2Yr9sxFd/FrKAUPQ== X-Received: by 2002:adf:ef0c:: with SMTP id e12mr33459264wro.170.1553931328813; Sat, 30 Mar 2019 00:35:28 -0700 (PDT) Received: from localhost (ip-94-113-223-73.net.upcbroadband.cz. [94.113.223.73]) by smtp.gmail.com with ESMTPSA id b10sm5253016wrt.86.2019.03.30.00.35.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 30 Mar 2019 00:35:28 -0700 (PDT) Date: Sat, 30 Mar 2019 08:35:27 +0100 From: Jiri Pirko To: Jakub Kicinski Cc: Linux Netdev List , David Miller , mlxsw@mellanox.com, Ido Schimmel , Florian Fainelli , Andrew Lunn , vivien.didelot@gmail.com, Michael Chan , Or Gerlitz Subject: Re: [patch net-next 00/12] net: expose switch ID via devlink Message-ID: <20190330073527.GB14297@nanopsycho> References: <20190328211254.1894-1-jiri@resnulli.us> <20190328144002.245c9eef@cakuba.netronome.com> <20190329064905.GS14297@nanopsycho> <20190329115926.5c16d2fd@cakuba.netronome.com> <20190329212153.GA14297@nanopsycho> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 11:34:14PM CET, jakub.kicinski@netronome.com wrote: >On Fri, Mar 29, 2019 at 2:21 PM Jiri Pirko wrote: >> 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. > >Ack, but switch id is a switchdev thing, controlling which ports are >considered to be part of the same device _for_ _switchdev_. "Switchdev" is a bridge offload. Nothing else. > >Is switchib doing forwarding? Not long ago Parav was convincing us >that switchdev mode for IB is pretty much meaningless. Even though >there are apparently representors for IB (judging by the recent RDMA >patchset on netdev)... Switch id is simply identifier for ports in general that belong to some switch. No matter if ethernet or IB. > >> >> 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. > >It's probably a matter of preference then. To me its very clear to say that >you can switch to physical/vf/pf ports and not cpu/dsa/host. I don't like >the duplication of dumpnig the same attribute both in rtnetlink and devlink. I want to remind you, that switch_id in rtnetlink was introduced before devlink existed. Back than, if was the only place to put it. However, as I explained, it is not ethernet speficic thing and rather belongs to devlink. This patchset is doing that. > >> Also, you can have multiple switches within one asic. > >That line is blurry. It is. So far, it is mlx CX hw that have basically 2 switches, one per PF. > >> >> >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. > >I see, so a dual port IB card would somehow have only one whatever the >equivalent of a netdev in IB world is? Yes. We have a patchset internally to manage that. > >> >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. > >Right, so to me switch ID really is a forwarding attribute.