Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2020-05-08T08:14:47Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/1173handle congestion recovery in multi-threading mode2020-05-08T08:14:47ZFrancis Duponthandle congestion recovery in multi-threading modeCurrently when the talk queue is full the server run_one method skips the receivePacket() call and returns.
This has a bad impact on mechanisms using external sockets because they are not served.
I propose to handle the congestion reco...Currently when the talk queue is full the server run_one method skips the receivePacket() call and returns.
This has a bad impact on mechanisms using external sockets because they are not served.
I propose to handle the congestion recovery inside the multi-threading code itself:
- make the congestion recovery disabled at configuration time when multi-threading is enabled
- change the task queue (aka ThreadPool) by a ringkea1.7.8Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/285Ring default capacity is far too high.2020-08-13T13:10:10ZFrancis DupontRing default capacity is far too high.Current value is 500 which is more than far too high. I propose to use 5 i.e. the same than the minimum value.
UPDATE: The code changes it to 64, not 5.Current value is 500 which is more than far too high. I propose to use 5 i.e. the same than the minimum value.
UPDATE: The code changes it to 64, not 5.kea1.8.0Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/276Congestion Handling should be ENABLED by default for Beta22018-11-26T19:44:02ZThomas MarkwalderCongestion Handling should be ENABLED by default for Beta2To increase the odds of testing occurring congestion handling should be on by default for BETA2.To increase the odds of testing occurring congestion handling should be on by default for BETA2.Kea1.5-beta2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/274Possible improvements to dhcp-queue-control member parsing2019-11-25T17:27:53ZThomas MarkwalderPossible improvements to dhcp-queue-control member parsingThe following discussion from !120 should be addressed:
- [ ] @fdupont started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/120#note_31593): (+1 comment)
> This can be postponed but the dhcp-queue-syntax i...The following discussion from !120 should be addressed:
- [ ] @fdupont started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/120#note_31593): (+1 comment)
> This can be postponed but the dhcp-queue-syntax is not defined enough:
> - you should create a context for the two keywords
> - to make it easy to extend just add a STRING COLON value rule (value is the generic JSON value defined at the beginning of dhcpX_parser.yy and is used for instance to define a generic mao, cf map_value rule)
@tmark
The basic rules for dhcp-queue-control are:
1. Require enable-queue
2. Ensure that if queue-type is specified, it is a string (it can have any arbitrary value)
3. beyond those two rules, it can contain arbitrary content
I wasn't sure how to go about accomplishing rule 3, and do not want to use user-context. The parsing that is in place does what is needed but I am open to suggestions.kea1.7.2Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/260Follow-up from "WIP: Resolve "Congestion handling - add receive thread and pa...2018-11-20T21:06:12ZMarcin SiodelskiFollow-up from "WIP: Resolve "Congestion handling - add receive thread and packet queue"The following discussions from !103 should be addressed:
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/103#note_28121): (+4 comments)
> I have some worries about this initialization pa...The following discussions from !103 should be addressed:
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/103#note_28121): (+4 comments)
> I have some worries about this initialization part being done in the thread and not really guarded from concurrent access to IfaceMgr. Although unlikely, there is a possibility that ifaces_ is modified while the thread is starting up. To mitigate this problem, the method which starts the thread should maybe wait for it to signal that it has been initialized and the for() loop has started. I mean, we should maybe revise the whole IfaceMgr to see whether something in it can be modified that is concurrently used in the thread and not allow such modification if the thread is running? Specifically, sockets and interfaces should not be touched while the thread is running because even the for() loop accesses them.
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/103#note_28138): (+3 comments)
> Parameters of the constructor aren't properly documented.
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/103#note_28180): (+4 comments)
> That deserves some comment.
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/103#note_28205): (+5 comments)
> I was scratching my head how is the new IfaceMgr code compatible with perfdhcp, which is also using receive4() and receive6() functions, but it doesn't (at least not explicitly) start receiver thread? On that matter, I also wonder if it shouldn't be optional to use the thread? perfdhcp probably doesn't want to drop any packets in the ring buffer?Kea1.5-beta2Thomas MarkwalderThomas Markwalder