netdev - Re: HSR/PRP LRE Stats - What is the right user space interface?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20200810132059.4840ac5c@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Mon, 10 Aug 2020 13:20:59 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Murali Karicheri <m-karicheri2@...com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        nikolay@...ulusnetworks.com
Subject: Re: HSR/PRP LRE Stats - What is the right user space interface?

On Mon, 10 Aug 2020 15:55:35 -0400 Murali Karicheri wrote:
> Hi Netdev experts,
> 
> IEC-62439 defines following LRE stats:-
> 
> 	"lreTxA",
> 	"lreTxB",
> 	"lreTxC",
> 	"lreErrWrongLanA",
> 	"lreErrWrongLanB",
> 	"lreErrWrongLanC",
> 	"lreRxA",
> 	"lreRxB",
> 	"lreRxC",
> 	"lreErrorsA",
> 	"lreErrorsB",
> 	"lreErrorsC",
> 	"lreNodes",
> 	"lreProxyNodes",
> 	"lreUniqueRxA",
> 	"lreUniqueRxB",
> 	"lreUniqueRxC",
> 	"lreDuplicateRxA",
> 	"lreDuplicateRxB",
> 	"lreDuplicateRxC",
> 	"lreMultiRxA",
> 	"lreMultiRxB",
> 	"lreMultiRxC",
> 	"lreOwnRxA",
> 	"lreOwnRxB",
> 
> These stats are defined also in the IEC-62439 MIB definition. So
> this MIB support is required in Net-SNMP and that requires a proper
> kernel interface to pull the values from the HSR or PRP
> LRE (Link Redundancy Entity). What is the right interface for this?
> Internally TI uses /proc interface for this. But want to check with
> community before sending a patch for this. One choice is ethtool for
> this. Or something else? Would appreciate if someone can clarify so
> that I can work towards a patch for the same.

Are these collected by HW, or also by the bridge code?

Adding a new IFLA_STATS_LINK_* may be the right choice.