From: Arnaldo Carvalho de Melo <acme@kernel•org>
To: David Miller <davem@davemloft•net>
Cc: dsahern@gmail•com, brouer@redhat•com, saeedm@mellanox•com,
mst@redhat•com, toke@toke•dk, netdev@vger•kernel.org,
pstaszewski@itcare•pl, jasowang@redhat•com
Subject: Re: consistency for statistics with XDP mode
Date: Mon, 3 Dec 2018 16:41:01 -0300 [thread overview]
Message-ID: <20181203194101.GD18717@kernel.org> (raw)
In-Reply-To: <20181203.113001.1705527415987837525.davem@davemloft.net>
Em Mon, Dec 03, 2018 at 11:30:01AM -0800, David Miller escreveu:
> From: David Ahern <dsahern@gmail•com>
> Date: Mon, 3 Dec 2018 08:45:12 -0700
>
> > On 12/1/18 4:22 AM, Jesper Dangaard Brouer wrote:
> >> IMHO XDP_DROP should not be accounted as netdev stats drops, this is a
> >> user installed program like tc/iptables, that can also choose to drop
> >> packets.
> >
> > sure and both tc and iptables have counters that can see the dropped
> > packets. A counter in the driver level stats ("xdp_drop" is fine with
> > with me).
>
> Part of the problem I have with this kind of logic is we take the choice
> away from the XDP program.
>
> If I feel that the xdp_drop counter bump is too much overhead during a
> DDoS attack and I want to avoid it, you don't give me a choice in the
> matter.
>
> If I want to represent the statistics for that event differently, you
> also give me no choice about it.
>
> Really, if XDP_DROP is returned, zero resources should be devoted to
> the frame past that point.
>
> I know you want to live in this magical world where XDP stuff behaves
> like the existing stack and give you all of the visibility to events
> and objects.
>
> But that is your choice.
>
> Please give others the choice to not live in that world and allow XDP
> programs to live in their own entirely different environment, with
> custom statistics and complete control over how counters are
> incremented and how objects are used and represented, if they choose
> to do so.
>
> XDP is about choice.
Coming out of the blue...: the presence of a "struct xdp_stats" in the
XDP program BPF object file .BTF section, one could query and the parse
to figure out what stats, if any, are provided.
/me goes back to tweaking his btf_loader in pahole... :-)
- Arnaldo
next prev parent reply other threads:[~2018-12-03 19:41 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
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 [this message]
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=20181203194101.GD18717@kernel.org \
--to=acme@kernel$(echo .)org \
--cc=brouer@redhat$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=dsahern@gmail$(echo .)com \
--cc=jasowang@redhat$(echo .)com \
--cc=mst@redhat$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pstaszewski@itcare$(echo .)pl \
--cc=saeedm@mellanox$(echo .)com \
--cc=toke@toke$(echo .)dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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