David Miller <da...@davemloft.net> writes:
> 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.
I wonder if it would be possible to support both the "give me user
normal stats" case and the "let me do whatever I want" case by a
combination of userspace tooling and maybe a helper or two?
I.e., create a "do_stats()" helper (please pick a better name), which
will either just increment the desired counters, or set a flag so the
driver can do it at napi poll exit. With this, the userspace tooling
could have a "--give-me-normal-stats" switch (or some other interface),
which would inject a call instruction to that helper at the start of the
program.
This would enable the normal counters in a relatively painless way,
while still letting people opt out if they don't want to pay the cost in
terms of overhead. And having the userspace tooling inject the helper
call helps support the case where the admin didn't write the XDP
programs being loaded.
Any reason why that wouldn't work?
-Toke
