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: <20160616.172632.1759391103978744570.davem@davemloft.net>
Date:	Thu, 16 Jun 2016 17:26:32 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	jiri@...nulli.us
Cc:	netdev@...r.kernel.org, nogahf@...lanox.com, idosch@...lanox.com,
	eladr@...lanox.com, yotamg@...lanox.com, ogerlitz@...lanox.com,
	roopa@...ulusnetworks.com, nikolay@...ulusnetworks.com,
	linville@...driver.com, tgraf@...g.ch, gospo@...ulusnetworks.com,
	sfeldma@...il.com, sd@...asysnail.net, eranbe@...lanox.com,
	ast@...mgrid.com, edumazet@...gle.com, hannes@...essinduktion.org,
	f.fainelli@...il.com
Subject: Re: [patch net-next v4 0/4] return offloaded stats as default and
 expose original sw stats

From: Jiri Pirko <jiri@...nulli.us>
Date: Thu, 16 Jun 2016 10:37:13 +0200

> Until now we had stats functions return SW statistics. However, it makes
> a lot of sense to return HW stats as default. The existing apps count with
> having the defaults stats complete, but that is not true now as the offloaded
> forward traffic is not visible there.
> 
> If user wants to know real SW stats, this patchset provides way to get
> it as well.

I think we haven't been very good about defining good rules nor
guidelines for how to handle HW vs SW stats, and I'm talking
strictly about what we publish via rtnl_link_stats64.

However, if I were working from scratch on a new driver what I would
be inclined to do is use HW stats for everything that the chip
provides direct and accurate support for, and fill in the gaps with SW
stats.

Because to me, stats are stats, the user wants to know (for example)
how many broadcast packets have gone through the port and doesn't care
how you obtain that number.

If the problem being addressed is that drivers aren't reporting
information on all the packets going through the device, then that's a
bug.

But it seems to me like mlxsw is already maintaining the software
statistic counters, so I can't see a performance reason for not
properly providing all of the statistics using HW vs. SW as is
appropriate for each and every value to fix this problem.  Why
create an entire new facility just for that?  It doesn't seem to
be needed.

Maybe you just need to describe things a bit more completely in this
header posting.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ