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;
Message-ID: <00659771ed54353f92027702c5bbb84702da62ce.camel@sipsolutions.net>
Subject: traceability of wifi packet drops
From:   Johannes Berg <johannes@sipsolutions.net>
To:     netdev@vger.kernel.org
Cc:     linux-wireless@vger.kernel.org
Date:   Mon, 27 Mar 2023 16:19:34 +0200
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) 
MIME-Version: 1.0
Precedence: bulk

Hi,

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_MON=
ITOR | 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?

Thanks,
johannes