From: Jiri Pirko <jiri@resnulli.us>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, nogahf@mellanox.com, idosch@mellanox.com,
eladr@mellanox.com, yotamg@mellanox.com, ogerlitz@mellanox.com,
roopa@cumulusnetworks.com, nikolay@cumulusnetworks.com,
linville@tuxdriver.com, tgraf@suug.ch, gospo@cumulusnetworks.com,
sfeldma@gmail.com, sd@queasysnail.net, eranbe@mellanox.com,
ast@plumgrid.com, edumazet@google.com,
hannes@stressinduktion.org, f.fainelli@gmail.com
Subject: Re: [patch net-next v4 0/4] return offloaded stats as default and expose original sw stats
Date: Fri, 17 Jun 2016 10:24:11 +0200 [thread overview]
Message-ID: <20160617082411.GA1981@nanopsycho.orion> (raw)
In-Reply-To: <20160616.172632.1759391103978744570.davem@davemloft.net>
Fri, Jun 17, 2016 at 02:26:32AM CEST, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.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.
The problem we try to handle is different, it's about offloaded
forwarded packets which are not seen by kernel. Let me try to draw it :)
port1 port2 (HW stats are counted here)
\ /
\ /
\ /
--(A)---- ASIC --(B)--
|
(C)
|
CPU (SW stats are counted here)
Now we have couple of flows for TX and RX (direction does not matter here):
1) port1->A->ASIC->C->CPU
For this flow, HW and SW stats are equal.
2) port1->A->ASIC->C->CPU->C->ASIC->B->port2
For this flow, HW and SW stats are equal.
3) port1->A->ASIC->B->port2
For this flow, SW stats are 0.
The purpose of this patchset is to provide facility for user to
find out the difference between flows 1+2 and 3. In other words, user
will be able to see the statistics for his slow-path (through kernel).
Also, as a default the accumulated stats (HW) will be exposed to user
so the userspace apps can react properly.
next prev parent reply other threads:[~2016-06-17 8:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-16 8:37 [patch net-next v4 0/4] return offloaded stats as default and expose original sw stats Jiri Pirko
2016-06-16 8:37 ` [patch net-next v4 1/4] netdevice: add SW statistics ndo Jiri Pirko
2016-06-16 8:37 ` [patch net-next v4 2/4] rtnetlink: add HW/SW stats distinction in rtnl_fill_stats Jiri Pirko
2016-06-16 8:37 ` [patch net-next v4 3/4] net: core: add SW stats to if_stats_msg Jiri Pirko
2016-06-17 0:20 ` David Miller
2016-06-17 7:32 ` Jiri Pirko
2016-06-16 8:37 ` [patch net-next v4 4/4] mlxsw: spectrum: Implement SW stats ndo and expose HW stats by default Jiri Pirko
2016-06-17 0:26 ` [patch net-next v4 0/4] return offloaded stats as default and expose original sw stats David Miller
2016-06-17 8:24 ` Jiri Pirko [this message]
2016-06-17 13:48 ` David Ahern
2016-06-17 14:05 ` Jiri Pirko
2016-06-17 14:54 ` Jamal Hadi Salim
2016-06-17 14:57 ` Jiri Pirko
2016-06-17 15:35 ` David Ahern
2016-06-17 15:42 ` Jiri Pirko
2016-06-17 17:12 ` Florian Fainelli
2016-06-18 8:00 ` Jiri Pirko
2016-06-18 13:58 ` Jamal Hadi Salim
2016-06-19 10:57 ` Jiri Pirko
2016-06-20 3:14 ` Roopa Prabhu
2016-06-20 12:28 ` Jamal Hadi Salim
2016-06-20 13:09 ` Jiri Pirko
2016-06-22 14:30 ` Roopa Prabhu
2016-06-20 3:06 ` Roopa Prabhu
2016-06-20 2:57 ` Roopa Prabhu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160617082411.GA1981@nanopsycho.orion \
--to=jiri@resnulli.us \
--cc=ast@plumgrid.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eladr@mellanox.com \
--cc=eranbe@mellanox.com \
--cc=f.fainelli@gmail.com \
--cc=gospo@cumulusnetworks.com \
--cc=hannes@stressinduktion.org \
--cc=idosch@mellanox.com \
--cc=linville@tuxdriver.com \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=nogahf@mellanox.com \
--cc=ogerlitz@mellanox.com \
--cc=roopa@cumulusnetworks.com \
--cc=sd@queasysnail.net \
--cc=sfeldma@gmail.com \
--cc=tgraf@suug.ch \
--cc=yotamg@mellanox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).