On Mon, Mar 27, 2023 at 6:32 PM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > 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. I am not going to comment on this idea directly, but I did want to note that long on my round-to-it list was adding something like this to the qdiscs generally: QDISC_DROP_REASON_CONGESTIVE QDISC_DROP_REASON_OVERFLOW QDISC_DROP_REASON_GSO_SPLIT since the wifi stack also has both of the former and for all I know, the latter, whatever you come up with I applaud, with a better name (QUEUE?) > > 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. -- AMA March 31: https://www.broadband.io/c/broadband-grant-events/dave-taht Dave Täht CEO, TekLibre, LLC
