Message-ID: <CAA93jw5vFdySU-AMGYPpj0fDOHNe9O0aL_3N1kDk7UPTAs63Tw@mail.gmail.com>
Date:   Mon, 27 Mar 2023 19:27:22 -0700
From:   Dave Taht <dave.taht@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Johannes Berg <johannes@...solutions.net>,
        Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org,
        linux-wireless@...r.kernel.org
Subject: Re: traceability of wifi packet drops

On Mon, Mar 27, 2023 at 6:32 PM Jakub Kicinski <kuba@...nel.org> 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

Powered by blists - more mailing lists