Mon, Jan 25, 2021 at 01:24:27PM CET, oleksandr.ma...@plvision.eu wrote: >Thu, Jan 21, 2021 at 06:36:05PM CET, k...@kernel.org wrote: >>On Thu, 21 Jan 2021 14:21:52 +0200 Ido Schimmel wrote: >>> On Thu, Jan 21, 2021 at 01:29:37PM +0200, Oleksandr Mazur wrote: >>> > 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. > >>+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.
