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;
Date:   Tue, 28 Mar 2023 15:58:26 -0700
From:   Jakub Kicinski <kuba@kernel.org>
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     Eric Dumazet <edumazet@google.com>, netdev@vger.kernel.org,
        linux-wireless@vger.kernel.org
Subject: Re: traceability of wifi packet drops
Message-ID: <20230328155826.38e9e077@kernel.org>
In-Reply-To: <abcf4b9aed8adad05841234dad103ced15f9bfb2.camel@sipsolutions.net>
References: <00659771ed54353f92027702c5bbb84702da62ce.camel@sipsolutions.net>
        <20230327180950.79e064da@kernel.org>
        <abcf4b9aed8adad05841234dad103ced15f9bfb2.camel@sipsolutions.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Tue, 28 Mar 2023 09:37:43 +0200 Johannes Berg wrote:
> > 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 

Thinking about it again, maybe yours is actually cleaner.
Having the subsystem reason on the top bits, I mean.
That way after masking the specific bits out the lower bits
can still provide a valid "global" drop reason.

The UNUSABLE vs MONITOR bits I'd be tempted to put in the "global"
reason, but maybe that's not a great idea given Eric's concern :)

> > 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.

Right, drop monitor is good ol' kernel code, we can make it do whatever
we want. I was worried that tracing / BPF may tie our hands but they
support sparse enums just fine.