Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 25 Jan 2021 15:56:14 +0100
From:   Jiri Pirko <jiri@resnulli.us>
To:     Oleksandr Mazur <oleksandr.mazur@plvision.eu>
Cc:     Jakub Kicinski <kuba@kernel.org>, Ido Schimmel <idosch@idosch.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "jiri@nvidia.com" <jiri@nvidia.com>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next] net: core: devlink: add new trap action
 HARD_DROP
Message-ID: <20210125145614.GM3565223@nanopsycho.orion>
References: <20210121112937.30989-1-oleksandr.mazur@plvision.eu>
 <20210121122152.GA2647590@shredder.lan>
 <20210121093605.49ba26ba@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
 <20210125121234.GJ3565223@nanopsycho.orion>
 <AM0P190MB07387522928B6730DBE1BB77E4BD0@AM0P190MB0738.EURP190.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <AM0P190MB07387522928B6730DBE1BB77E4BD0@AM0P190MB0738.EURP190.PROD.OUTLOOK.COM>
Precedence: bulk

Mon, Jan 25, 2021 at 01:24:27PM CET, oleksandr.mazur@plvision.eu wrote:
>Thu, Jan 21, 2021 at 06:36:05PM CET, kuba@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.