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:37:15 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     David Ahern <dsahern@...il.com>
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 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?