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

[Ido Schimmel]

On Mon, Jan 25, 2021 at 03:56:14PM +0100, Jiri Pirko wrote:
> Mon, Jan 25, 2021 at 01:24:27PM CET, oleksandr.mazur@xxxxxxxxxxx wrote:
> >Thu, Jan 21, 2021 at 06:36:05PM CET, kuba@xxxxxxxxxx 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.

>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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
[2] https://lore.kernel.org/netdev/20210123160348.GB2799851@xxxxxxxxxxxx/