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

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

On Wed, May 24, 2017 at 12:33 AM, Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
> On Tue, May 23, 2017 at 08:56:10AM -0400, Thor Lancelot Simon wrote:
>> > 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?
>
> I guess this then requires a callout. It may be more overhead than
> always scheduling the softint.

I've looked the codes of bouyer-socketcan. I think can_input doesn't need
softinit-ification because can_input just soon calls schednetisr(NETISR_CAN)
and doesn't involve other network components that assume running in
softint. What we need to do on Rx is just to replace bpf_mtap with
bpf_mtap_softint. (You may need to implement can_bpf_mtap_softint or the like).

On Tx, the current implementation is a bit different from ordinary drivers
and needs some refactoring. I've written a patch that fills the gap:
  http://www.netbsd.org/~ozaki-r/awin_can.diff
It moves the Tx operation from awin_can_tx_intr to awin_can_ifstart
and lets awin_can_tx_intr use the deferred if_start mechanism to kick
if_start if needed.

It doesn't require softint on per-Tx on normal load. Under heavy load,
the deferred if_start may be triggered and that involves softint though.

How about the change?
  ozaki-r