Date: Fri, 10 Apr 2020 09:49:51 +0300 From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= <ozkan.kirik@gmail.com> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, freebsd-ipfw <freebsd-ipfw@freebsd.org>, "Andrey V. Elsukov" <bu7cher@yandex.ru> Subject: Re: dummynet performance Message-ID: <CAAcX-AGCk6jrOQMhHxGc5b1V_e-3Xmsq24fgt9scVtVHr64acA@mail.gmail.com> 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
Thanks! On Thu, Apr 9, 2020 at 8:29 PM Luigi Rizzo <rizzo@iet.unipi.it> wrote: > On Thu, Apr 9, 2020 at 2:18 AM =C3=96zkan KIRIK <ozkan.kirik@gmail.com> w= rote: > > > > 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 assigne= d > to > > different thread. > > - By default, all schedulers assigned to thread 0 if no thread_id is se= t. > > With a new option named "thr_id" affinity can be set. as below: > > ipfw sched 1 config type QFQ (by defaut thr_id =3D 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 sam= e > > 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 designe= d > 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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAAcX-AGCk6jrOQMhHxGc5b1V_e-3Xmsq24fgt9scVtVHr64acA>