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 either from
.bss/.data 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 are 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 devices 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
