Hi Joerg, Thanks for your comment!
On Fri, Jan 15, 2016 at 6:43 AM, Joerg Sonnenberger <jo...@britannica.bec.de> wrote: > On Thu, Jan 14, 2016 at 07:19:03PM +0900, Ryota Ozaki wrote: >> One possible objection should be performance >> degradation, however I believe we can mitigate >> by introducing polling packet processing >> like Linux and FreeBSD do. Of course, we also >> have to rethink existing sofint (L3 softints >> and bridge_forward softint). > > While I agree with the goal and also that fast-forward shouldn't stop > this, I would like to see some numbers for the performance impact under > load and maybe the latency change without load. Any chance to test for > that? I'm preparing performance numbers. They'll come early in the next week. > >> BTW, this proposal includes another change; >> move bpf_mtap to a common place, not doing it >> in each driver. This change is also needed by >> the above proposal to ensure to always run bpf >> in softint. > > Be careful, there are multiple BPF hooks in some drivers, e.g. the > WiFi stack. Hmm. Okay, I'll check all hooks... BTW, I forgot noting that ipi_sysinit in main() needed a tweak to use pktq_create in driver attach routines. The tweak is like this finally: http://www.netbsd.org/~ozaki-r/fix-ipi_sysinit.diff pktq_create calls softint_establish with SOFTINT_RCPU and then softint_establish calls ipi_register which depends on ipi_sysinit is finished. However, driver attach routines are called in configure() in main() that is prior to ipi_sysinit. So I need to move ipi_sysinit to a place before configure(). Unfortunately, the original ipi_sysinit depends on ncpu that is determined after configure() so I have to divide ipi_sysinit into two: one is for softint_establish and moved to a place before configure(), and the other depending on ncpu is kept at the original place. I confirmed it works on amd64, but I'm not sure the change doesn't break other archs. Could someone expert on IPI check it? Thanks, ozaki-r
