tech-net archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: RFC: softint-based if_input
Date: Tue, 9 Feb 2016 10:30:57 +0900
From: Ryota Ozaki <ozaki-r%netbsd.org@localhost>
On Tue, Feb 9, 2016 at 1:34 AM, Taylor R Campbell
<campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
> (For the record, the issues were spurious reinitialization of
> ifp->if_percpuq in if_iwm and if_rtwn causing a memory leak, and a
> needless whitespace change in if_otus -- all residual from earlier
> drafts.)
Allocating ifp->if_percpuq in if_iwm and if_rtwn is correct because
if_initialize/if_register don't allocate it.
Oops. I sit corrected!
> Are there any ieee80211 drivers that already do anything in softint?
> At a cursory glance, I don't see any. So the conditional is probably
> not necessary
No, not yet (except USB drivers). I can remove the conditional (but
we have to keep in mind to change there when we change ieee80211
and/or individual Wifi drivers).
Sure.
> -- and this is an argument for (in a future change)
> exposing the callback for if_percpuq so that ieee80211 can do
> if_perpcuq_dequeue/ieee80211_input, not if_percpuq_dequeue/if_input,
> in a loop.
I'm worried we would have to make rxintr of Wifi drivers softint
in order to run all bpf hooks in softint because bpf hooks exit
before ieee80211_input. If we can move them into ieee80211_input,
we don't need such big changes though, I'm not sure yet if we can.
It sounds reasonable to me to push ieee80211_input into softint, in a
future change. It is not substantially different from ether_input,
except we usually call ieee80211_input directly whereas we usually
call ether_input via ifp->if_input -- mainly, I suspect, so that it
can be replaced by bridge_input.
Home |
Main Index |
Thread Index |
Old Index