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.ki...@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-unsubscr...@freebsd.org"
--
Best regards,
Alexandr B. Baryshnyev, e-mail: a...@abbon.net
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
