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

On Mon, 27 Mar 2023 16:19:34 +0200 Johannes Berg wrote:
> So I just ran into this problem with a colleague again; we don't have
> good visibility into why in the wifi stack a packet is dropped.
> 
> In the network stack we have skb drop reasons for (part of?) this, but
> we don't really use this in wifi/mac80211 yet.
> 
> Unfortunately we have probably >100 distinct drop reasons in the wifi
> stack, so annotating those is not only tedious, it would also double the
> list of SKB drop reasons from currently ~75.
> 
> Any good ideas? I even thought about just encoding the line number
> wherever we use RX_DROP_UNUSABLE / RX_DROP_MONITOR, but that's kind of
> awkward too. Obviously we could change the internal API to completely
> get rid of enum ieee80211_rx_result and use enum skb_drop_reason
> instead, but then we'd probably need to carve out some space to also
> differentiate DROP_MONITOR and DROP_UNUSABLE, perhaps something like
> 
> 
> 	SKB_DROP_REASON_MAC80211_MASK		0x03ff0000
> 	SKB_DROP_REASON_MAC80211_TYPE_MASK	0x03000000
> 	SKB_DROP_REASON_MAC80211_TYPE_UNUSABLE	0x01000000
> 	SKB_DROP_REASON_MAC80211_TYPE_MONITOR	0x02000000
> 
> 	SKB_DROP_REASON_MAC80211_DUP		(SKB_DROP_REASON_MAC80211_TYPE_UNUSABLE | 1)
> 	SKB_DROP_REASON_MAC80211_BAD_BIP_KEYIDX	(SKB_DROP_REASON_MAC80211_TYPE_MONITOR | 1)
> 
> 
> etc.
> 
> 
> That'd be a LOT of annotations (and thus work) though, and a lot of new
> IDs/names, for something that's not really used all that much, i.e. a
> file number / line number within mac80211 would be completely
> sufficient, so the alternative could be to just have a separate
> tracepoint inside mac80211 with a line number or so?
> 
> 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.

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.

On a quick look nothing is indexed by the reason directly, so no
problems with using the high bits.

Option #2 is to add one main drop reason called SKB_DROP_REASON_MAC80211
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.

Those are perhaps fairly obvious and unimaginative. Adding Eric,
since he has been filling in a lot of the drop reasons lately.