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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E07A0C433F5 for ; Tue, 4 Oct 2022 06:56:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229484AbiJDG4V (ORCPT ); Tue, 4 Oct 2022 02:56:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37348 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229676AbiJDG4U (ORCPT ); Tue, 4 Oct 2022 02:56:20 -0400 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 133EA2D77F for ; Mon, 3 Oct 2022 23:56:19 -0700 (PDT) Received: by mail-ej1-x630.google.com with SMTP id b2so26814079eja.6 for ; Mon, 03 Oct 2022 23:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=+tcn9B7Ym8UONbEc5EvJpUWZ3bzMEiRSGSgK5uDh3Sc=; b=ic3g3krgCZxWT2MmFGd0e131DBRZaVGX4SX7ueo5RYe4yrJOBu9UjJJq21eTtuHlwI 1Us8YtCkExouFVIhzLrZ9mVKOEl94t/XEDZf3W6D6dXA0kHGbQs8lcPlDcewdjmbysMi LFyHjWHAQC7KfkcXPfBLaOA9ugwVn+xqRP8iS/55+yFCkZje+bwyOrdxjXYfyiutl0UK jHQywcdko5pN9iNdp662Xz6HO3+5Wkis+09uKcYCo8wVyXFWAUUiCDJMNUony8sGOZyL epr7+7wMqHYwzNMX8hpr1oOI0LvViTzA4NnbzsRWN+pYkSnlgaoPeNX/plVi/7fpaoI5 NT8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=+tcn9B7Ym8UONbEc5EvJpUWZ3bzMEiRSGSgK5uDh3Sc=; b=0ub80RRAM+KL66CGDCn5HMbD2i0kqT1XRDwC+b25SJz84i/FBoSCnxl68HzhtngMK8 nSB/mAZMJC5BgjwCzdEUonj+/EnKqufhh0OnPLNxyMKCqQjiUA7KNTlGthO0OqFVd6qr QjzMD/31dW48jdorpj/Vog213BjA11Rg23j8CMFyN0FPgmuHmcF831S3cJ4vVbKQXKv8 2Ta143rEnh9/ExO6Dk/Pv/FLnJuXSiv4yOt487cFjRVBL/rFBvSsdHwYKyHA3NsTCbDJ E7hS/bwXvr1KVoxUbUvNhOUANc99uPY3inXLiRHWm1Im0giIKnSMxtVdwl7NmRHmfOux 3zYw== X-Gm-Message-State: ACrzQf0oeTx+W9zohrstYICcTeweEr9EN4ODSLkXbQ9BvE9Lcq+5z7d1 JwDaMIU5QVKSmHr/Egw8j3dDOg== X-Google-Smtp-Source: AMsMyM6q7CanQFsXNr9PR5MUNCDJkkeS0Fb8NDXZLxXrJWUQ38BsN/3e2MM+M6lhZxSoagpmZvRbMA== X-Received: by 2002:a17:907:724e:b0:783:5fba:4298 with SMTP id ds14-20020a170907724e00b007835fba4298mr19360005ejc.28.1664866577564; Mon, 03 Oct 2022 23:56:17 -0700 (PDT) Received: from localhost ([86.61.181.4]) by smtp.gmail.com with ESMTPSA id g25-20020a056402321900b004542e65337asm1046089eda.51.2022.10.03.23.56.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Oct 2022 23:56:16 -0700 (PDT) Date: Tue, 4 Oct 2022 08:56:16 +0200 From: Jiri Pirko To: Jakub Kicinski Cc: netdev@vger.kernel.org, davem@davemloft.net, pabeni@redhat.com, edumazet@google.com, tariqt@nvidia.com, moshe@nvidia.com, saeedm@nvidia.com, linux-rdma@vger.kernel.org Subject: Re: [patch net-next v2 00/13] net: fix netdev to devlink_port linkage and expose to user Message-ID: References: <20221003105204.3315337-1-jiri@resnulli.us> <20221003094556.1f16a255@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221003094556.1f16a255@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org Mon, Oct 03, 2022 at 06:45:56PM CEST, kuba@kernel.org wrote: >On Mon, 3 Oct 2022 12:51:51 +0200 Jiri Pirko wrote: >> Currently, the info about linkage from netdev to the related >> devlink_port instance is done using ndo_get_devlink_port(). >> This is not sufficient, as it is up to the driver to implement it and >> some of them don't do that. Also it leads to a lot of unnecessary >> boilerplate code in all the drivers. >> >> Instead of that, introduce a possibility for driver to expose this >> relationship by new SET_NETDEV_DEVLINK_PORT macro which stores it into >> dev->devlink_port. It is ensured by the driver init/fini flows that >> the devlink_port pointer does not change during the netdev lifetime. >> Devlink port is always registered before netdev register and >> unregistered after netdev unregister. >> >> Benefit from this linkage setup and remove explicit calls from driver >> to devlink_port_type_eth_set() and clear(). Many of the driver >> didn't use it correctly anyway. Let the devlink.c to track associated >> netdev events and adjust type and type pointer accordingly. Also >> use this events to to keep track on ifname change and remove RTNL lock >> taking from devlink_nl_port_fill(). >> >> Finally, remove the ndo_get_devlink_port() ndo which is no longer used >> and expose devlink_port handle as a new netdev netlink attribute to the >> user. That way, during the ifname->devlink_port lookup, userspace app >> does not have to dump whole devlink port list and instead it can just >> do a simple RTM_GETLINK query. > >Would you be okay if we deferred until 6.2? > >It's technically past the deadline and some odd driver could regress. Sure.