From: Thomas Markwalder Date: Tue, 5 May 2026 12:31:36 +0000 (-0400) Subject: [#4489] A few more nits. X-Git-Tag: Kea-3.1.9~115 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=bed8b94e3388e5ca86605dbfcab7f8a8fd0c5e37;p=thirdparty%2Fkea.git [#4489] A few more nits. modified: doc/sphinx/arm/dhcp4-srv.rst modified: doc/sphinx/arm/dhcp6-srv.rst --- diff --git a/doc/sphinx/arm/dhcp4-srv.rst b/doc/sphinx/arm/dhcp4-srv.rst index 9c39d7db32..797f0d9814 100644 --- a/doc/sphinx/arm/dhcp4-srv.rst +++ b/doc/sphinx/arm/dhcp4-srv.rst @@ -8977,7 +8977,7 @@ are described in detail in later sections. +------------------+-----------------------------+------------------------------+-----------------------+------------------------------+----------------+ | Free Lease Queue | high | high | yes | slow (depends on pool sizes) | high (varying) | +------------------+-----------------------------+------------------------------+-----------------------+------------------------------+----------------+ - | Shared FLQ | high | high | partial, pools within | slow when adding it's use; | low | + | Shared FLQ | high | high | partial, pools within | slow when adding its use; | low | | | | | subnets are random | fast once added | | +------------------+-----------------------------+------------------------------+-----------------------+------------------------------+----------------+ @@ -9190,16 +9190,17 @@ We recommend that the SFLQ allocator be selected only after careful consideratio As discussed above, impact on startup can be substantial when introducing the use of SFLQ. Creating the initial SFLQ data for large pools (e.g.``/8``) may delay the server's startup by several seconds or more per pool. It is faster for smaller pools -(e.g.``/16`` or less) but per pool can add up when they are many such pools. We -recommend specifying another allocator type at the global level and specifying -the SFLQ allocator at the subnet or shared-network level only for select subnets. +(e.g.``/16`` or less) but per pool can add up when there are many such pools. To +reduce this startup cost we recommend specifying another allocator type at the global +level and specifying the SFLQ allocator at the subnet or shared-network level only +for select subnets. There is another important aspect of the SFLQ Allocator that warrants discussion. As mentioned above when a server is using SFLQ allocation for a given pool, it uses specialized back end updates that maintain the SFLQ data. Thus it is critical that all servers sharing a lease back end agree on which subnets use SFLQ allocation. If they do not agree the SFLQ data will quickly become inaccurate. Addresses may -look free when they are not vice versa. In the case of the former, the allocation +look free when they are not and vice versa. In the case of the former, the allocation engine will detect an existing lease and try another. In the case of the latter, the lease will not be offered. @@ -9209,7 +9210,7 @@ the lease will not be offered. using SFLQ allocation, it be done in maintenance windows such that servers are not actively serving clients for those subnets while the changes are made. This will avoid inconsistencies in SFLQ data. - + SFLQ data is tracked in terms of pools where each pool has a start address and an end address. Configuration changes that change the address range of a pool or split into multiple new pools will trigger SFLQ data creation diff --git a/doc/sphinx/arm/dhcp6-srv.rst b/doc/sphinx/arm/dhcp6-srv.rst index 62731959f3..21a960e54d 100644 --- a/doc/sphinx/arm/dhcp6-srv.rst +++ b/doc/sphinx/arm/dhcp6-srv.rst @@ -8794,7 +8794,7 @@ are described in detail in later sections. +------------------+-----------------------------+------------------------------+-----------------------+------------------------------+----------------+ | Free Lease Queue | high | high | yes | slow (depends on pool sizes) | high (varying) | +------------------+-----------------------------+------------------------------+-----------------------+------------------------------+----------------+ - | Shared FLQ | high | high | partial, pools within | slow when adding it's use; | low | + | Shared FLQ | high | high | partial, pools within | slow when adding its use; | low | | | | | subnets are random | fast once added | | +------------------+-----------------------------+------------------------------+-----------------------+------------------------------+----------------+ @@ -9019,16 +9019,16 @@ As discussed above, impact on startup can be substantial when introducing the us of SFLQ. Creating the initial SFLQ data for large pools (e.g. > 500K addresses or prefixes) may delay the server's startup by several seconds or more per pool. It is faster for smaller pools (e.g. 65K addresses or prefixes) but per pool can add up -when they are many such pools. We recommend specifying another allocator type at -the global level and specifying the SFLQ allocator at the subnet or shared-network -level only for select subnets. +when there are many such pools. To reduce this startup cost we recommend specifying +another allocator type at the global level and specifying the SFLQ allocator at the +subnet or shared-network level only for select subnets. There is another important aspect of the SFLQ Allocator that warrants discussion. As mentioned above when a server is using SFLQ allocation for a given pool, it uses specialized back end updates that maintain the SFLQ data. Thus it is critical that all servers sharing a lease back end agree on which subnets use SFLQ allocation. If they do not agree the SFLQ data will quickly become inaccurate. Addresses may -look free when they are not vice versa. In the case of the former, the allocation +look free when they are not and vice versa. In the case of the former, the allocation engine will detect an existing lease and try another. In the case of the latter, the lease will not be offered.