[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Deferred if_start
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:
Only drivers that call if_deferred_start_init have a new softint for
>> 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 :-|
> 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.
Main Index |
Thread Index |