netdev - Re: [RFC PATCH net-next 0/6] devlink: Add device metric support

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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 21 Aug 2020 17:59:57 -0600
From:   David Ahern <dsahern@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Ido Schimmel <idosch@...sch.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        netdev@...r.kernel.org, davem@...emloft.net, jiri@...dia.com,
        amcohen@...dia.com, danieller@...dia.com, mlxsw@...dia.com,
        roopa@...dia.com, andrew@...n.ch, vivien.didelot@...il.com,
        tariqt@...dia.com, ayal@...dia.com, mkubecek@...e.cz,
        Ido Schimmel <idosch@...dia.com>
Subject: Re: [RFC PATCH net-next 0/6] devlink: Add device metric support

On 8/21/20 5:50 PM, Jakub Kicinski wrote:
> On Fri, 21 Aug 2020 13:12:59 -0600 David Ahern wrote:
>> On 8/21/20 10:53 AM, Jakub Kicinski wrote:
>>> How many times do I have to say that I'm not arguing against the value
>>> of the data? 
>>>
>>> If you open up this interface either someone will police it, or it will
>>> become a dumpster.  
>>
>> 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.

> 
> # cat /proc/net/tls_stat 

I do not agree with adding files under /proc/net for this.

> 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. 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).

####

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?