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=-4.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,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 2E47EC43381 for ; Mon, 4 Mar 2019 23:32:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E2100204FD for ; Mon, 4 Mar 2019 23:32:19 +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="bj8x++jQ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726590AbfCDXcT (ORCPT ); Mon, 4 Mar 2019 18:32:19 -0500 Received: from mail-qt1-f193.google.com ([209.85.160.193]:37901 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726066AbfCDXcS (ORCPT ); Mon, 4 Mar 2019 18:32:18 -0500 Received: by mail-qt1-f193.google.com with SMTP id s1so7118993qte.5 for ; Mon, 04 Mar 2019 15:32:17 -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=fDj24hK8Qle590WzTudGiEALE6Q180ozueUlPk0P/Ms=; b=bj8x++jQv5bYzrGw2Ic0GiezzZwHZBJNF4d5ihLhyhIOjlkkuJExdHsaptSZgQEmpo LaI7/yfvY5Us1v2D0LiuiUknzKIsfVj9SdFhr69idt1Omy9MbW7gIqyhPJfk2ET4hA9n zz0gO0/Fqb+GZu0JYotkTe+qfym7xyxX0KSyE1QJ3WyJL2cau4XutgJEfwtx4N6rMUEv 6OY9iHYeU3UG6rb3GIffrtHbNZD6ecY/Zq3BkRW9J8ts3oh3yWDlqOSoMZdUdrB0Mrx/ NuMchdtk6VOQpwa5VAUQ5TlkYXUahWHRe/afA/3vcf1Z4wCEeIihheltJZWePottCQ8u l9Hw== 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=fDj24hK8Qle590WzTudGiEALE6Q180ozueUlPk0P/Ms=; b=uctRIRZ1FmXT7vMwrjl9dK+gXXPDe8FRz91S6TBvxJU23VaY2j1S8xhrHKKROOoM4B MJ4387bE2lLsK7/xl4ZlCM6+tm6uHCN3hoTMjvch9lL9GVaH6BvctFSufyONASl9Gs4D pJbfdFj1rBA/SpjJYsMQH+nWO9WA2vFBcOKfTIypgO8A1VVkmBHklMX223TPZRJnYppV JqMq7E+DHs/VyHgDaGhh3Ewf03PpkfGoMLNlmDGxKCMxQM2bmjOvTwQw2iLBDAm5Wonx qfmj9sUeEDB10KjjFbc4N/PRXiZEgqfVpigX9s8/epqgYH22bpTLpsut+8+15pxgGrrI fOUg== X-Gm-Message-State: APjAAAVzuXYesK9AUAoZFAkcJqRRI0NmdOlbvbRgstUnbwAxZw1J58JE boXO/LzpYKvParjGpmsQq7bFqg== X-Google-Smtp-Source: APXvYqxZ2yDuQGdEFzHdiLW5vK+Qepak08BFa9WtGJLsrY/CO0/rN+A3mB2w4UsZVvFNK/yXZB7MMw== X-Received: by 2002:aed:3b7b:: with SMTP id q56mr16406889qte.115.1551742337245; Mon, 04 Mar 2019 15:32:17 -0800 (PST) Received: from cakuba.netronome.com ([66.60.152.14]) by smtp.gmail.com with ESMTPSA id o2sm5324620qtf.46.2019.03.04.15.32.15 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 04 Mar 2019 15:32:16 -0800 (PST) Date: Mon, 4 Mar 2019 15:32:10 -0800 From: Jakub Kicinski To: Jiri Pirko Cc: davem@davemloft.net, netdev@vger.kernel.org, oss-drivers@netronome.com Subject: Re: [PATCH net-next v2 3/7] nfp: register devlink ports of all reprs Message-ID: <20190304153210.5fc4f9af@cakuba.netronome.com> In-Reply-To: <20190304073631.GU2314@nanopsycho> References: <20190301180453.17778-1-jakub.kicinski@netronome.com> <20190301180453.17778-4-jakub.kicinski@netronome.com> <20190302084347.GP2314@nanopsycho> <20190302110724.75d1bdf5@cakuba.netronome.com> <20190304073631.GU2314@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 Mon, 4 Mar 2019 08:36:31 +0100, Jiri Pirko wrote: > >> >+ case NFP_PORT_PF_PORT: > >> >+ return devlink_port_register(devlink, &port->dl_port, > >> >+ (port->pf_id + 1) * 10000 + > >> >+ port->pf_split_id * 1000); > >> > >> Wait. What this 10000/1000 magic about? > > > >port_index has to be unique, I need some unique number here, as I > >stated both in the commit message and the cover letter, this is > >arbitrary. > > You can at least use some defines for that. Ok. > >I can put the datapath port identifier in there but its (a) > >meaningless, (b) a bitfield, so it will look like 8972367083. And it > >may change depending on the FW load, so its not stable either. > >> > void nfp_devlink_port_unregister(struct nfp_port *port) > >> >diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c b/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c > >> >index d2c803bb4e56..869d22760a6e 100644 > >> >--- a/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c > >> >+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c > >> >@@ -395,12 +397,24 @@ int nfp_repr_init(struct nfp_app *app, struct net_device *netdev, > >> > if (err) > >> > goto err_clean; > >> > > >> >- err = register_netdev(netdev); > >> >+ err = nfp_devlink_port_init(app, repr->port); > >> > if (err) > >> > goto err_repr_clean; > >> > > >> >+ err = register_netdev(netdev); > >> >+ if (err) > >> >+ goto err_port_clean; > >> >+ > >> >+ err = nfp_devlink_port_register(app, repr->port); > >> > >> Don't you want to take my patch ("nfp: register devlink port before > >> netdev") to change order of register_netdev and devlink_port_register, > >> include it to this patchset before this patch and change the order in > >> this patch too? I think it would be clearer to do it from the beginning. > > > >This way both netdev and devlink_port can get registered fully > >initialized. Otherwise we'd get two notifications. Are we trying to > >establish some ordering rules to get around the rtnl locking? :) > > The order of devlink_port_register and register_netdev is given by > layering. For example, for port change, the devlink_port is still there > and registered, only the netdev is unregistered and ib_dev registered > instead of vice versa. It has really no relation to rtnl locking. Ok, I shouldn't worry about the notifications too much, I agree the order you suggests makes sense in principal.