Hi, On 2016/05/20 22:02, Taylor R Campbell wrote: > Date: Fri, 20 May 2016 16:28:15 +0900 > From: Kengo NAKAHARA <k-nakah...@iij.ad.jp> > > I back to gif(4) MP-ify, since I could eliminate bottleneck of > MP-scalable bridge(4) to support wm(4) TX multiqueue. > > I rebase my gif(4) MP-ify patches and reflect latest psref(9) and > pslist(9) implementation. Here is the patch series. > http://www.netbsd.org/~knakahara/gif-psref/gif-psref.tgz > And here is the unified patch. > http://www.netbsd.org/~knakahara/gif-psref/unified-gif-psref.patch
I rebase and improve the patches. Here is the updated patch series. http://www.netbsd.org/~knakahara/gif-mpify/gif-mpify.tgz And here is the unified patch. http://www.netbsd.org/~knakahara/gif-mpify/unified-gif-mpify.patch > Nice! I don't have time to review it right now, but I'll try to find > some time in the next few days. Have you done any throughput tests > yet, or tried observing the effect of `ifconfig gif1 create' on the > flow through gif0? I'm particularly curious to see how bad it is to > just encap drop packets while `ifconfig gif1 create' is running. I measure the throughput, however the effect is very little, that is, nearly equal to accidental error. Additionally I create 1024 gif(4)s, and then measure gif0 throughput while doing "ifconfig gif1025 create". The "ifconfig gif1025 create" effect is less than 1 percent(about 0.2%) degradation. In contrast, "ifconfig gif1 create" become slow while it flow nearly limit performance packets on gif0. It takes about 2 or 3 seconds. Furthermore, "ifconfig gif1025 create" become very slow under the same condition. It takes over 10 seconds, or over 20 seconds in worst case. # of course, if gif0 has no flow, ifconfigs finish immediately If there is no objection, I will commit them after a few days or a few weeks. Thanks, -- ////////////////////////////////////////////////////////////////////// Internet Initiative Japan Inc. Device Engineering Section, IoT Platform Development Department, Network Division, Technology Unit Kengo NAKAHARA <k-nakah...@iij.ad.jp>