Date: Mon, 13 Apr 2020 02:13:53 +0300 From: Alexandr Baryshnyev <abb@abbon.net> To: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, freebsd-ipfw <freebsd-ipfw@freebsd.org> Subject: Re: dummynet performance Message-ID: <e8553dd0-0a44-b470-4f99-f89513f56d46@abbon.net> In-Reply-To: <CA%2BhQ2%2BgDeEYFWt%2B5guFVTvsSyeL_M4KRUif6nzTpFcu=hLrVOQ@mail.gmail.com> References: <CAAcX-AEamLFbAucFXYJ0k3FePddYC7M-OtQRsTgQ3UWz_z%2BBBA@mail.gmail.com> <CA%2BhQ2%2BgDeEYFWt%2B5guFVTvsSyeL_M4KRUif6nzTpFcu=hLrVOQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dear Luigi! The fact that the regular FreeBSD shaper Dummynet is still single-threaded is the reason that many people switch to using Linux. This is a real problem that really limits the use of the FreeBSD system as a high-speed router and shaper. I understand that this is not an easy task, but most likely no one but you can do it now. Please, correct the source code of the Dummynet and make it multi-threaded! I think a lot of people who still use FreeBSD will be very grateful to you. Can we hope that this problem will be resolved by you in the foreseeable future? In any case, thank you very much for your work! 09.04.2020 20:28, Luigi Rizzo wrote: > On Thu, Apr 9, 2020 at 2:18 AM Özkan KIRIK <ozkan.kirik@gmail.com> wrote: >> >> Hello, >> >> I wonder if it is possible to update dummynet code multi-threading capable >> practically? >> My idea is below: >> - A new sysctl tunable will be defined as >> "net.inet.ip.dummynet.thread_count" (default 1) >> - To distribute tasks along threads, each sched instance can be assigned to >> different thread. >> - By default, all schedulers assigned to thread 0 if no thread_id is set. >> With a new option named "thr_id" affinity can be set. as below: >> ipfw sched 1 config type QFQ (by defaut thr_id = 0) >> ipfw sched 2 config type QFQ thr_id 1 >> ipfw sched 3 config type QFQ thr_id 2 >> ipfw sched 4 config type FIFO thr_id 3 >> ipfw sched 5 config type FIFO thr_id 3 ( sched 4 & 5 assigned to same >> thread 3 ) >> >> I think this approach is more easy then completely rewrite or other >> solutions. >> > > This change may not be completely trivial given that dummynet was designed as > single threaded and protected by a single lock. > > If you want to proceed, you should do as follows: > - some members of struct dn_parms need to be duplicated for each thread, > including prev_t, evheap, curr_time, the locks, and perhaps others. > Probably may be useful to create a new struct for them, with a back > pointer to the parent dn_parms, and include a refcount. > > - add another rwlock to protect access to dn_cfg > > - dummynet_io() does the initial demultiplexing calling dn_ht_find(), > currently protected DN_BH_WLOCK(). This could be changed to an RWLOCK > and I believe this initial step could be protected by a read lock > (maybe there are corner cases where you need to create a new entry > so you need to drop the lock, acquire in write mode and retry...) > > - once the demux has returned a dn_fsk, maybe you can use a refcount > to avoid the object being destroyed, release the read lock on > dn_cfg.fshash, acquire an exclusive lock on the thread handling the > dn_fsk, and proceed from there. > > - the kernel thread that process the heap should now run each on > one instance of the evheap > > cheers > luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Best regards, Alexandr B. Baryshnyev, e-mail: abb@abbon.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e8553dd0-0a44-b470-4f99-f89513f56d46>