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.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 2DB69C433E1 for ; Sat, 22 Aug 2020 00:37:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0A50320735 for ; Sat, 22 Aug 2020 00:37:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598056641; bh=1l/sa+Xka3m6RIxwDV25ezDu08+V9MT1LtFKB+Q7F4Q=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=wGmQA5u3b6KHjO7bl6oxsGyr0rA0li3JJvsxQHLdmGcRUurweeW5V41Nn5UkY45W4 Obrmo5/ZWUi88fBIaexIJ6t4gupnzFNO8JCNTMaBazjTARWiLpJA5AKxF1UjH8MqbR uuyRp92OAyqBKOObORhRiKFMI46UNTvE78FV7HAg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726905AbgHVAhU (ORCPT ); Fri, 21 Aug 2020 20:37:20 -0400 Received: from mail.kernel.org ([198.145.29.99]:50886 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726688AbgHVAhT (ORCPT ); Fri, 21 Aug 2020 20:37:19 -0400 Received: from kicinski-fedora-PC1C0HJN (unknown [163.114.132.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 030B72072D; Sat, 22 Aug 2020 00:37:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598056638; bh=1l/sa+Xka3m6RIxwDV25ezDu08+V9MT1LtFKB+Q7F4Q=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=eGsHPjnT6CwKYRTFpOFF7UdkjM8uu+hTmlEc1m5HU9L2LAPmkNN9ERJ+SrI5Krk3Q 69NaPbfrydlO7UQNG4mL8FIph60otuf6HXiKhZ8TQ6NwNpjhTbJk989bhgxqkAqhYX V7d8+jVSjbnrnC5m90EU93G79hg6Uf1yjQR3TKJE= Date: Fri, 21 Aug 2020 17:37:15 -0700 From: Jakub Kicinski To: David Ahern Cc: Ido Schimmel , Florian Fainelli , netdev@vger.kernel.org, davem@davemloft.net, jiri@nvidia.com, amcohen@nvidia.com, danieller@nvidia.com, mlxsw@nvidia.com, roopa@nvidia.com, andrew@lunn.ch, vivien.didelot@gmail.com, tariqt@nvidia.com, ayal@nvidia.com, mkubecek@suse.cz, Ido Schimmel Subject: Re: [RFC PATCH net-next 0/6] devlink: Add device metric support Message-ID: <20200821173715.2953b164@kicinski-fedora-PC1C0HJN> In-Reply-To: <1e5cdd45-d66f-e8e0-ceb7-bf0f6f653a1c@gmail.com> References: <20200817125059.193242-1-idosch@idosch.org> <20200818172419.5b86801b@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <58a0356d-3e15-f805-ae52-dc44f265661d@gmail.com> <20200818203501.5c51e61a@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <55e40430-a52f-f77b-0d1e-ef79386a0a53@gmail.com> <20200819091843.33ddd113@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20200819110725.6e8744ce@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20200820090942.55dc3182@kicinski-fedora-PC1C0HJN> <20200821103021.GA331448@shredder> <20200821095303.75e6327b@kicinski-fedora-PC1C0HJN> <6030824c-02f9-8103-dae4-d336624fe425@gmail.com> <20200821165052.6790a7ba@kicinski-fedora-PC1C0HJN> <1e5cdd45-d66f-e8e0-ceb7-bf0f6f653a1c@gmail.com> 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 Fri, 21 Aug 2020 17:59:57 -0600 David Ahern wrote: > On 8/21/20 5:50 PM, Jakub Kicinski wrote: > > On Fri, 21 Aug 2020 13:12:59 -0600 David Ahern wrote: > >> I am not following what you are proposing as a solution. You do not like > >> Ido's idea of stats going through devlink, but you are not being clear > >> on what you think is a better way. > >> > >> You say vxlan stats belong in the vxlan driver, but the stats do not > >> have to be reported on particular netdevs. How then do h/w stats get > >> exposed via vxlan code? > > > > No strong preference, for TLS I've done: > > But you clearly *do* have a strong preference. I'm answering your question. The question is "How then do h/w stats get exposed via vxlan code?" Please note that the question includes "via vxlan code". So no, I have no preference as long as it's "via vxlan code", and not directly from the driver with a vendor-invented name. > > # cat /proc/net/tls_stat > > I do not agree with adding files under /proc/net for this. Yeah it's not the best, with higher LoC a better solution should be within reach. > > TlsCurrTxSw 0 > > TlsCurrRxSw 0 > > TlsCurrTxDevice 0 > > TlsCurrRxDevice 0 > > TlsTxSw 0 > > TlsRxSw 0 > > TlsTxDevice 0 > > TlsRxDevice 0 > > TlsDecryptError 0 > > TlsRxDeviceResync 0 > > > > We can add something over netlink, I opted for simplicity since global > > stats don't have to scale with number of interfaces. > > IMHO, netlink is the right "channel" to move data from kernel to > userspace, and opting in to *specific* stats is a must have feature. > > I think devlink is the right framework given that the stats are device > based but not specific to any particular netdev instance. I'd be careful with the "not specific to any particular netdev instance". A perfect API would be flexible when it comes to scoping :) > Further, this > allows discrimination of hardware stats from software stats which if > tied to vxlan as a protocol and somehow pulled from the vxan driver > those would be combined into one (at least how my mind is thinking of this). Right, for tls the stats which have "Device" in the name are hardware. But netlink will have better ways of separating the two. > #### > > Let's say the direction is for these specific stats (as opposed to the > general problem that Ido and others are considering) to be pulled from > the vxlan driver. How does that driver get access to hardware stats? > vxlan is a protocol and not tied to devices. How should the connection > be made? Drivers which offload VxLAN already have a dependency on it, right? They can just registers to it and get queried on dump. Or if we want scoping we can piggyback on whatever object stats are scoped to. *If* we scope on HW objects do we need to worry about some user some day wanting to have stats per vxlan netdev and per HW instance?