All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: netdev@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Subject: traceability of wifi packet drops
Date: Mon, 27 Mar 2023 16:19:34 +0200	[thread overview]
Message-ID: <00659771ed54353f92027702c5bbb84702da62ce.camel@sipsolutions.net> (raw)

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_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?

Thanks,
johannes

             reply	other threads:[~2023-03-27 14:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-27 14:19 Johannes Berg [this message]
2023-03-27 14:31 ` traceability of wifi packet drops Johannes Berg
2023-03-28  1:09 ` Jakub Kicinski
2023-03-28  2:27   ` Dave Taht
2023-03-28  7:37   ` Johannes Berg
2023-03-28  8:16     ` Eric Dumazet
2023-03-28  8:18       ` Johannes Berg
2023-03-28 22:58     ` Jakub Kicinski
2023-03-29  8:35       ` Johannes Berg
2023-03-29 18:02         ` Jakub Kicinski
2023-03-29 18:57           ` Johannes Berg
2023-03-29 19:09             ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=00659771ed54353f92027702c5bbb84702da62ce.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.