Em Mon, Dec 03, 2018 at 11:30:01AM -0800, David Miller escreveu:
> From: David Ahern <dsah...@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
