All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: David Ahern <dsahern@gmail.com>,
	"netdev\@vger.kernel.org" <netdev@vger.kernel.org>
Cc: "Paweł Staszewski" <pstaszewski@itcare.pl>,
	"Jesper Dangaard Brouer" <brouer@redhat.com>,
	"Saeed Mahameed" <saeedm@mellanox.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"David Miller" <davem@davemloft.net>
Subject: Re: consistency for statistics with XDP mode
Date: Wed, 21 Nov 2018 22:14:44 +0100	[thread overview]
Message-ID: <874lca2kvv.fsf@toke.dk> (raw)
In-Reply-To: <1d9a6548-4d1d-6624-e808-6ab0460a8655@gmail.com>

David Ahern <dsahern@gmail.com> writes:

> Paweł ran some more XDP tests yesterday and from it found a couple of
> issues. One is a panic in the mlx5 driver unloading the bpf program
> (mlx5e_xdp_xmit); he will send a send a separate email for that
> problem.

Same as this one, I guess?

https://marc.info/?l=linux-netdev&m=153855905619717&w=2

> The problem I wanted to discuss here is statistics for XDP context. The
> short of it is that we need consistency in the counters across NIC
> drivers and virtual devices. Right now stats are specific to a driver
> with no clear accounting for the packets and bytes handled in XDP.
>
> For example virtio has some stats as device private data extracted via
> ethtool:
> $ ethtool -S eth2 | grep xdp
>     ...
>      rx_queue_3_xdp_packets: 5291
>      rx_queue_3_xdp_tx: 0
>      rx_queue_3_xdp_redirects: 5163
>      rx_queue_3_xdp_drops: 0
>     ...
>      tx_queue_3_xdp_tx: 5163
>      tx_queue_3_xdp_tx_drops: 0
>
> And the standard counters appear to track bytes and packets for Rx, but
> not Tx if the packet is forwarded in XDP.
>
> Similarly, mlx5 has some counters (thanks to Jesper and Toke for helping
> out here):
>
> $ ethtool -S mlx5p1 | grep xdp
>      rx_xdp_drop: 86468350180
>      rx_xdp_redirect: 18860584
>      rx_xdp_tx_xmit: 0
>      rx_xdp_tx_full: 0
>      rx_xdp_tx_err: 0
>      rx_xdp_tx_cqe: 0
>      tx_xdp_xmit: 0
>      tx_xdp_full: 0
>      tx_xdp_err: 0
>      tx_xdp_cqes: 0
>     ...
>      rx3_xdp_drop: 86468350180
>      rx3_xdp_redirect: 18860556
>      rx3_xdp_tx_xmit: 0
>      rx3_xdp_tx_full: 0
>      rx3_xdp_tx_err: 0
>      rx3_xdp_tx_cqes: 0
>     ...
>      tx0_xdp_xmit: 0
>      tx0_xdp_full: 0
>      tx0_xdp_err: 0
>      tx0_xdp_cqes: 0
>     ...
>
> And no accounting in standard stats for packets handled in XDP.
>
> And then if I understand Jesper's data correctly, the i40e driver does
> not have device specific data:
>
> $ ethtool -S i40e1  | grep xdp
> [NOTHING]
>
>
> But rather bumps the standard counters:
>
> sudo ./xdp_rxq_info --dev i40e1 --action XDP_DROP
>
> Running XDP on dev:i40e1 (ifindex:3) action:XDP_DROP options:no_touch
> XDP stats       CPU     pps         issue-pps
> XDP-RX CPU      1       36,156,872  0
> XDP-RX CPU      total   36,156,872
>
> RXQ stats       RXQ:CPU pps         issue-pps
> rx_queue_index    1:1   36,156,878  0
> rx_queue_index    1:sum 36,156,878
>
>
> $ ethtool_stats.pl --dev i40e1
>
> Show adapter(s) (i40e1) statistics (ONLY that changed!)
> Ethtool(i40e1   ) stat:   2711292859 (  2,711,292,859) <= port.rx_bytes /sec
> Ethtool(i40e1   ) stat:      6274204 (      6,274,204) <=
> port.rx_dropped /sec
> Ethtool(i40e1   ) stat:     42363867 (     42,363,867) <=
> port.rx_size_64 /sec
> Ethtool(i40e1   ) stat:     42363950 (     42,363,950) <=
> port.rx_unicast /sec
> Ethtool(i40e1   ) stat:   2165051990 (  2,165,051,990) <= rx-1.bytes /sec
> Ethtool(i40e1   ) stat:     36084200 (     36,084,200) <= rx-1.packets /sec
> Ethtool(i40e1   ) stat:         5385 (          5,385) <= rx_dropped /sec
> Ethtool(i40e1   ) stat:     36089727 (     36,089,727) <= rx_unicast /sec
>
>
> We really need consistency in the counters and at a minimum, users
> should be able to track packet and byte counters for both Rx and Tx
> including XDP.
>
> It seems to me the Rx and Tx packet, byte and dropped counters returned
> for the standard device stats (/proc/net/dev, ip -s li show, ...) should
> include all packets managed by the driver regardless of whether they are
> forwarded / dropped in XDP or go up the Linux stack. This also aligns
> with mlxsw and the stats it shows which are packets handled by the hardware.
>
> From there the private stats can include XDP specifics as desired --
> like the drops and redirects but that those should be add-ons and even
> here some consistency makes life easier for users.
>
> The same standards should be also be applied to virtual devices built on
> top of the ports -- e.g,  vlans. I have an API now that allows bumping
> stats for vlan devices.
>
> Keeping the basic xdp packets in the standard counters allows Paweł, for
> example, to continue to monitor /proc/net/dev.
>
> Can we get agreement on this? And from there, get updates to the mlx5
> and virtio drivers?

I'd say it sounds reasonable to include XDP in the normal traffic
counters, but having the detailed XDP-specific counters is quite useful
as well... So can't we do both (for all drivers)?

-Toke

  reply	other threads:[~2018-11-22  7:50 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-21 21:06 consistency for statistics with XDP mode David Ahern
2018-11-21 21:14 ` Toke Høiland-Jørgensen [this message]
2018-11-21 21:29   ` Paweł Staszewski
2018-11-22  0:21     ` Saeed Mahameed
2018-11-22  8:26       ` Toke Høiland-Jørgensen
2018-11-22 16:51         ` David Ahern
2018-11-22 17:00           ` Toke Høiland-Jørgensen
2018-11-30 20:10             ` Saeed Mahameed
2018-11-30 20:30               ` Michael S. Tsirkin
2018-11-30 20:35                 ` David Ahern
2018-12-01  4:41                   ` Jakub Kicinski
2018-12-01 11:14                     ` Jesper Dangaard Brouer
2018-12-03 15:56                       ` David Ahern
2018-12-03 19:32                         ` David Miller
2018-11-30 23:54                 ` Saeed Mahameed
2018-12-01 11:22                   ` Jesper Dangaard Brouer
2018-12-03 15:45                     ` David Ahern
2018-12-03 19:30                       ` David Miller
2018-12-03 19:41                         ` Arnaldo Carvalho de Melo
2018-12-03 20:00                         ` Toke Høiland-Jørgensen
2018-12-04  0:00                           ` David Miller
2018-12-04  0:15                             ` David Ahern
2018-12-04  0:36                               ` David Miller
2018-12-04  7:03                                 ` Toke Høiland-Jørgensen
2018-12-04  7:24                                   ` Jakub Kicinski
2018-12-04  9:29                                     ` Jesper Dangaard Brouer
2018-12-04 17:56                                       ` Jakub Kicinski
2018-12-04 18:06                                       ` Michael S. Tsirkin
2018-11-24  7:07           ` David Miller
2018-11-22  0:53 ` Toshiaki Makita
2018-11-22 16:43   ` David Ahern
2018-11-26  1:37     ` Toshiaki Makita
2018-11-27  7:04       ` Toshiaki Makita
2018-11-28  4:03         ` Jason Wang
2018-11-28  5:09           ` Toshiaki Makita
2018-11-26 22:15 ` Jakub Kicinski

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=874lca2kvv.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=brouer@redhat.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pstaszewski@itcare.pl \
    --cc=saeedm@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.