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