Re: status of bpf_mtap()/bpf_mtap_softint() ?

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Tue, May 23, 2017 at 12:41 AM, Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
> Hello
> looking more closely at bpf for CAN, there is something I don't understand.
> It looks like bpf_mtap() can't be called from interrupt context any more,
> as shown by the KASSERT() in bpf_deliver().
> bpf_mtap_softint() was was introduced for this.

bpf_mtap needs different treatments for Rx and Tx.

For Rx, network device drivers should (1) implement the Rx interrupt handler
as sofint or (2) use if_percpuq facility to ensure the interface input
routine (traditionally it's ifp->if_input) and bpf_mtap (and upper layers)
run in softint. Most drivers need to just use if_percpuq_enqueue instead of
ifp->if_input.

bpf_mtap_softint was introduced for bpf_mtap that were difficult to run
it in softint (e.g., to do so, fundamental changes are needed). Basically
we shouldn't use bpf_mtap_softint and should adopt either of the above two
approaches.

For Tx, bpf_mtap is called in XXX_start that is normally executed in
a normal packet transmission path (LWP or softint). However, some drivers
try to call XXX_start in the Tx interrupt handler. To avoid such calls,
the deferred if_start mechanism was introduced. What we need is just to
replace XXX_start called in an interrupt handler with
if_schedule_deffered_start.

>
> But it looks like most ethernet drivers will still call bpf_mtap() from
> hardware interrupt context.
> For example, if_tl.c calls bpf_mtap() from tl_ifstart(), which is called
> on TX interrpt. ic/hme.c is another example.
>
> Did I miss somehing, or have these drivers missed some conversion (and
> have not been tested with a DIAGNOSTIC kernel) ?

Just passed over to convert... I fixed some more drivers including the two.
Let me know if there are others to convert.

  ozaki-r