[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: status of bpf_mtap()/bpf_mtap_softint() ?
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:
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?
Main Index |
Thread Index |