dnsdist: Document that setTCPUseSinglePipe should not be used anymore

diff --git a/pdns/dnsdistdist/docs/advanced/tuning.rst b/pdns/dnsdistdist/docs/advanced/tuning.rst
index 72454ad9e2661455b0e8e5ef5130889e6ce9c600..01884f93e25deb00fbde45f735c9c90047350357 100644 (file)
--- a/pdns/dnsdistdist/docs/advanced/tuning.rst
+++ b/pdns/dnsdistdist/docs/advanced/tuning.rst
@@ -26,14 +26,14 @@ Any value larger than 0 will cause new connections to be dropped if there are al
 By default, every TCP worker thread has its own queue, and the incoming TCP connections are dispatched to TCP workers on a round-robin basis.
 This might cause issues if some connections are taking a very long time, since incoming ones will be waiting until the TCP worker they have been assigned to has finished handling its current query, while other TCP workers might be available.
 
-The experimental :func:`setTCPUseSinglePipe` directive can be used so that all the incoming TCP connections are put into a single queue and handled by the first TCP worker available.
+The experimental :func:`setTCPUseSinglePipe` directive can be used so that all the incoming TCP connections are put into a single queue and handled by the first TCP worker available. This used to be useful before 1.4.0 because a single connection could block a TCP worker, but the "one pipe per TCP worker" is preferable now that workers can handle multiple connections to prevent waking up all idle workers when a new connection arrives.
 
 Rules and Lua
 -------------
 
 Most of the query processing is done in C++ for maximum performance, but some operations are executed in Lua for maximum flexibility:
 
- * Rules added by :func:`addLuaAction`
+ * Rules added by :func:`LuaAction`, :func:`LuaResponseAction`, :func:`LuaFFIAction` or :func:`LuaFFIResponseAction`
  * Server selection policies defined via :func:`setServerPolicyLua`, :func:`setServerPolicyLuaFFI`, :func:`setServerPolicyLuaFFIPerThread` or :func:`newServerPolicy`
 
 While Lua is fast, its use should be restricted to the strict necessary in order to achieve maximum performance, it might be worth considering using LuaJIT instead of Lua.
@@ -81,4 +81,4 @@ Lock contention and sharding
 
 Adding more threads makes it possible to use more CPU cores to deal with the load, but at the cost of possibly increasing lock contention between threads. This is especially true for Lua-intensive setups, because Lua processing in dnsdist is serialized by a unique lock for all threads.
 For other components, like the packet cache and the in-memory ring buffers, it is possible to reduce the amount of contention by using sharding. Sharding divides the memory into several pieces, every one of these having its own separate lock, reducing the amount of times two threads or more will need to access the same data.
-Sharding is disabled by default and can be enabled via the `newPacketCache` option to :func:`newPacketCache` and :func:`setRingBuffersSize`.
+Sharding is disabled by default and can be enabled via the `numberOfShards` option to :func:`newPacketCache` and :func:`setRingBuffersSize`.

diff --git a/pdns/dnsdistdist/docs/reference/tuning.rst b/pdns/dnsdistdist/docs/reference/tuning.rst
index 4ceaef264bb13490ffaabaab0e35f1d96c62cf7f..2f1462b1f0674e73f10e88264b1a9770f98579a4 100644 (file)
--- a/pdns/dnsdistdist/docs/reference/tuning.rst
+++ b/pdns/dnsdistdist/docs/reference/tuning.rst
@@ -73,7 +73,9 @@ Tuning related functions
 
 .. function:: setTCPUseSinglePipe(val)
 
-  Whether the incoming TCP connections should be put into a single queue instead of using per-thread queues. Defaults to false
+  .. deprecated:: 1.6.0
+
+  Whether the incoming TCP connections should be put into a single queue instead of using per-thread queues. Defaults to false. That option was useful before 1.4.0 when a single TCP connection could block a TCP worker thread, but should not be used in recent versions where the per-thread queues model avoids waking up all idle workers when a new connection arrives.
 
   :param bool val: