Re: [PATCH net-next] net: core: devlink: add new trap action HARD_DROP

On Mon, Jan 25, 2021 at 03:56:14PM +0100, Jiri Pirko wrote:

Mon, Jan 25, 2021 at 01:24:27PM CET, oleksandr.mazur@plvision.eu wrote:

quoted

Thu, Jan 21, 2021 at 06:36:05PM CET, kuba@kernel.org wrote:

quoted

On Thu, 21 Jan 2021 14:21:52 +0200 Ido Schimmel wrote:

quoted

On Thu, Jan 21, 2021 at 01:29:37PM +0200, Oleksandr Mazur wrote:

quoted

Add new trap action HARD_DROP, which can be used by the
drivers to register traps, where it's impossible to get
packet reported to the devlink subsystem by the device
driver, because it's impossible to retrieve dropped packet
from the device itself.
In order to use this action, driver must also register
additional devlink operation - callback that is used
to retrieve number of packets that have been dropped by
the device.  

Are these global statistics about number of packets the hardware dropped
for a specific reason or are these per-port statistics?

It's a creative use of devlink-trap interface, but I think it makes
sense. Better to re-use an existing interface than creating yet another
one.

Not sure if I agree, if we can't trap why is it a trap?
It's just a counter.

quoted

+1

Device might be unable to trap only the 'DROP' packets, and this information should be transparent for the user.

I agree on the statement, that new action might be an overhead.
I could continue on with the solution Ido Schimmel proposed: since no new action would be needed and no UAPI changes are required, i could simply do the dropped statistics (additional field) output added upon trap stats queiring.
(In case if driver registerd callback, of course; and do so only for DROP actions)

It is not "a trap". You just need to count dropped packet. You don't
trap anything. That is why I don't think this has anything to do with
"trap" infra.

From [1] I understand that it is a trap and the action can be switched,
but when it is 'drop', the hardware can provide statistics about number
of packets that were discarded in hardware. If this is correct, then the
suggestion in [2] looks valid to me.

[1] https://lore.kernel.org/netdev/AM0P190MB073828252FFDA3215387765CE4A00@AM0P190MB0738.EURP190.PROD.OUTLOOK.COM/ (local)
[2] https://lore.kernel.org/netdev/20210123160348.GB2799851@shredder.lan/ (local)