Re: Deferred if_start

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

On Mon, Dec 5, 2016 at 6:54 PM, Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
> On Mon, Dec 05, 2016 at 12:16:42PM +0900, Ryota Ozaki wrote:
>> On Fri, Dec 2, 2016 at 7:55 PM, Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
>> > Especially on older systems, adding non-trivial overhead to RX
>> > processing can be costly, especially if the technical reasons are
>> > questionable. So let's look at those reasons again.
>>
>> I think it's trivial because deferred if_start only runs if it's
>> requested and the check if it's requested is executed per multiple
>> packets, not per packet.
>
> Please remember, I'm not arguing about if_start, but changing RX
> processing to include another softint layer.

I think we can unify Rx softint and Tx sofint as pq3etsec driver does,
but okay I don't include the design in this proposal and add a softint
for deferred if_start.

This is a new patch including complete changes:
  http://www.netbsd.org/~ozaki-r/if_deferred_start.complete.diff

Only drivers that call if_deferred_start_init have a new softint for
deferred if_start.

>
>> BTW, how about moving bpf_mtap (and ifp->if_ipackets++) from each driver
>> to the common percpuq if_input? That's also a requirement for MP-safe bpf.
>
> That would work at least for Ethernet drivers. It would actually be nice
> to recheck the function pointer at this point, e.g. the way VLAN
> processing is hooked up is somewhat gross, but that's unrelated.

bridge(4) already changes if_input thought, hmm... that's future work :-|

> You
> should keep in mind though that some drivers (e.g. WLAN) have multiple
> bpf_mtap hooks to include the signal statistics etc.

Yes, I know. nonakap@ will tackle the ieee80211 stack and wifi drivers.

Thanks,
  ozaki-r