On Tue, Mar 28, 2023 at 12:37 AM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Mon, 2023-03-27 at 18:09 -0700, Jakub Kicinski wrote: > > > 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. > > Fair enough. > > > 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. > > Right. That's not _that_ far from what I proposed above, except you pull > the core out > > > On a quick look nothing is indexed by the reason directly, so no > > problems with using the high bits. > > I think you missed he drop_reasons[] array in skbuff.c, but I guess we > could just not add these to the DEFINE_DROP_REASON() macro (and couldn't > really add them anyway). > > The only user seems to be drop_monitor, which anyway checks the array > bounds (in the trace hit function.) > > Or we change the design of this to actually have each subsystem provide > an array/a callback for their namespace, if the strings are important? > Some registration/unregistration might be needed for modules, but that > could be done. > > > 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. > > Yeah, I considered doing that with just the line number, but who knows > what people might want to use this for in the end, so that's not a great > idea either I guess :-) > > I would prefer the version with the drop reasons, since then also you > only have to worry about one tracepoint. > About visibility: Even before 'drop reasons' developers can always use the call graph . perf record -a -g -e skb:kfree_skb ... Really drop reasons are nice when you want filtering and convenience. But they are a lot of work to add/maintain. This all comes at a cost (both maintenance but also run time cost because we need to propagate reasons )
