Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <00659771ed54353f92027702c5bbb84702da62ce.camel@sipsolutions.net>
 <20230327180950.79e064da@kernel.org> <abcf4b9aed8adad05841234dad103ced15f9bfb2.camel@sipsolutions.net>
In-Reply-To: <abcf4b9aed8adad05841234dad103ced15f9bfb2.camel@sipsolutions.net>
From:   Eric Dumazet <edumazet@google.com>
Date:   Tue, 28 Mar 2023 01:16:23 -0700
Message-ID: <CANn89iJn6xmCK8VfJVAqhod9C=nNrqR6OprYKbWO-rrZXxoe_g@mail.gmail.com>
Subject: Re: traceability of wifi packet drops
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     Jakub Kicinski <kuba@kernel.org>, netdev@vger.kernel.org,
        linux-wireless@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Mar 28, 2023 at 12:37=E2=80=AFAM Johannes Berg
<johannes@sipsolutions.net> wrote:
>
> On Mon, 2023-03-27 at 18:09 -0700, Jakub Kicinski wrote:
> > > Anyone have any great ideas?
> >
> > We need something that'd scale to more subsystems, so I don't think
> > having all the definitions in enum skb_drop_reason directly is an
> > option.
>
> Fair enough.
>
> > My knee jerk idea would be to either use the top 8 bits of the
> > skb reason enum to denote the space. And then we'd say 0 is core
> > 1 is wifi (enum ieee80211_rx_result) etc. Within the WiFi space
> > you can use whatever encoding you like.
>
> Right. That's not _that_ far from what I proposed above, except you pull
> the core out
>
> > On a quick look nothing is indexed by the reason directly, so no
> > problems with using the high bits.
>
> I think you missed he drop_reasons[] array in skbuff.c, but I guess we
> could just not add these to the DEFINE_DROP_REASON() macro (and couldn't
> really add them anyway).
>
> The only user seems to be drop_monitor, which anyway checks the array
> bounds (in the trace hit function.)
>
> Or we change the design of this to actually have each subsystem provide
> an array/a callback for their namespace, if the strings are important?
> Some registration/unregistration might be needed for modules, but that
> could be done.
>
> > Option #2 is to add one main drop reason called SKB_DROP_REASON_MAC8021=
1
> > and have a separate tracepoint which exposes the detailed wifi
> > reason and any necessary context. mac80211 would then have its own
> > wrapper around kfree_skb_reason() which triggers the tracepoint.
>
> Yeah, I considered doing that with just the line number, but who knows
> what people might want to use this for in the end, so that's not a great
> idea either I guess :-)
>
> I would prefer the version with the drop reasons, since then also you
> only have to worry about one tracepoint.
>

About visibility: Even before 'drop reasons' developers can always use
the call graph .

perf record -a -g -e skb:kfree_skb ...

Really drop reasons are nice when you want filtering and convenience.
But they are a lot of work to add/maintain.
This all comes at a cost (both maintenance but also run time cost
because we need to propagate reasons )