[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20181203.113001.1705527415987837525.davem@davemloft.net>
Date: Mon, 03 Dec 2018 11:30:01 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: dsahern@...il.com
Cc: brouer@...hat.com, saeedm@...lanox.com, mst@...hat.com,
toke@...e.dk, netdev@...r.kernel.org, pstaszewski@...are.pl,
jasowang@...hat.com
Subject: Re: consistency for statistics with XDP mode
From: David Ahern <dsahern@...il.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.
Powered by blists - more mailing lists