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

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Tue, May 23, 2017 at 12:33:37PM +0200, Manuel Bouyer wrote:
> On Tue, May 23, 2017 at 11:51:39AM +0900, Ryota Ozaki wrote:
> > 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.
> 
> thanks.
> For CAN this is quite a bit of overhead. CAN controllers usually don't do
> DMA and can handle only one packet at a time. This means one extra softint
> per received packet, and eventually one extra softint per transmitted packet.

Is it possible to coalesce -- accumulate packets until a given count, or
enough time passes, and then schedule the softint?

Thor