netdev - Re: [RFC net-next 1/2] net: net-porcfs: Reduce rcu lock critical section

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]

Message-ID: <1523911853.4579.19.camel@mellanox.com>
Date:   Mon, 16 Apr 2018 20:50:56 +0000
From:   Saeed Mahameed <saeedm@...lanox.com>
To:     "eric.dumazet@...il.com" <eric.dumazet@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC net-next 1/2] net: net-porcfs: Reduce rcu lock critical
 section

On Thu, 2018-04-12 at 19:12 +0000, Saeed Mahameed wrote:
> On Wed, 2018-04-11 at 19:59 -0700, Eric Dumazet wrote:
> > 
> > On 04/11/2018 04:47 PM, Saeed Mahameed wrote:
> > > 
> > > Well if we allow devices to access HW counters via FW command
> > > interfaces in ndo_get_stats and by testing mlx5 where we query up
> > > to 5
> > > hw registers, it could take 100us, still this is way smaller than
> > > 10sec
> > >  :) and it is really a nice rate to fetch HW stats on demand.
> > 
> > If hardware stats are slower than software ones, maybe it is time
> > to
> > use software stats,
> > instead of changing the whole stack ?
> > 
> 
> We already have SW stats for [rx/tx]_[packets/bytes] but for
> [rx/tx]_[error/drop] etc .. they can only be grabbed from HW.
> 
> We don't want to report only partial counters to get_stats ndo just
> to
> avoid sleeping.
> 
> > There are very few devices drivers having issues like that.
> > 

Dave, Eric, I would like to know whether it is ok to have this change
in the kernel (make get_stats ndo "might sleep")? I really didn't get
any convincing feedback to not do this change.

For smart nics where a lot of statistics computations and
driver/Hardware communication go through Firmware, there is not much we
can do in the driver in order to provide accurate and "fresh"
statistics other than talking directly to Firmware through command
interfaces that "might sleep". Currently this is done through a
background thread caching hardware statistics 5 times a second which is
wasteful.

In order to complete this work I need to take care of netlink, ovs and
bonding (similar to what i did in this patch).

Plus I might need to introduce a new dev hold/put API that guarantees
the netdev is not uninitialized while it is being briefly held, this is
needed since the current device chain locks guarantees that by design.
(Should be a relatively small change).

Go/No Go?

Thanks,
Saeed.