xiaoxiang781216 commented on code in PR #7525:
URL: https://github.com/apache/nuttx/pull/7525#discussion_r1038801808


##########
net/tcp/tcp_conn.c:
##########
@@ -586,16 +586,32 @@ FAR struct tcp_conn_s *tcp_alloc_conn(void)
 
 void tcp_initialize(void)
 {
-#ifndef CONFIG_NET_ALLOC_CONNS
   int i;
 
+#ifndef CONFIG_NET_ALLOC_CONNS
   for (i = 0; i < CONFIG_NET_TCP_CONNS; i++)
     {
       /* Mark the connection closed and move it to the free list */
 
       g_tcp_connections[i].tcpstateflags = TCP_CLOSED;
       dq_addlast(&g_tcp_connections[i].sconn.node, &g_free_tcp_connections);
     }
+#else
+  FAR struct tcp_conn_s *conn;
+
+  for (i = 0; i < CONFIG_NET_TCP_PREALLOC_CONNS; i++)
+    {
+      conn = kmm_zalloc(sizeof(struct tcp_conn_s));

Review Comment:
   > I sincerely do not understand your proposition. I need the following:
   > 
   > * It is impossible to know the maximum number of connections before-hand. 
Thus I need dynamic connections allocation.
   > * I know that a temporal high-load condition may happen. After this 
finishes, the connections must be deallocated to allow the system to reuse the 
memory. It must not keep the never-to-be-used-again memory reserved!
   
   This can simply achieve to set CONFIG_NET_CONNS to 1, and alloc/free conn.
   
   > * I know that at least _some_ connections are always needed, and I need 
them preallocated to reduce heap fragmentation, enhance performance, and reduce 
locking of the system (as the memory manager may do).
   > 
   
   it can achieve with new NET_TCP_PREALLOC_CONNS, you can allocate from .bss 
or heap in batch, both approach is fine.
   
   > All the above sound like very reasonable and possibly common requirements 
for a networking application. In fact, I cannot imagine a system with unknown 
number of connections behave any differently.
   
   Yes, I think all is the reasonable requirement.
   
   > Point 2 is especially important for safety and security reasons.
   > 
   
   Point 2 is important for the device which accept the connection from client, 
but many IoT device only contain client side functionality and never accept the 
new connection. In the second case, it's safe to not release conn to heap, but 
put into the free list:
   
   1. Allocate conn in batch to avoid the heap overhead
   2. Avoid the memory fragment by reducing malloc/free operation
   3. Improve the speed
   
   > Your proposal cannot satisfy all 3 requirements, at least as far as I can 
understand it.
   
   Please reference my suggestion here:
   https://github.com/apache/nuttx/pull/7525#discussion_r1038789173
   And point out which's function you want can't achieve, let improve it case 
by case.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to