zhhyu7 commented on PR #17358: URL: https://github.com/apache/nuttx/pull/17358#issuecomment-3767373249
> > Surely but with 10.3.0 atleast IOB could get full and not deadlock this easily, right now the first occurence of a full with IOB with TCP traffic yields a deadlock for me, This is most likely more logical/state machine problem. > > Hi @PetervdPerk-NXP , The issue of the protocol stack getting stuck, caused by the case where TCP cannot process TCP_ACK because the transmit queue fills up the IOB so the driver fails to allocate an IOB, which in turn leads to the inability to release TCP write buffer resources, should have always existed, especially in scenarios where the total amount of iob is small, such as less than 16k. Another scenario that can cause the protocol stack getting stuck is when the application never reads the packets in the protocol stack's readahead. The probability of the second scenario occurring can be reduced by limiting CONFIG_NET_RECV_BUFSIZE. > > Let's focus on the first scenario. To avoid the occurrence of this scenario. If it is a scenario where CONFIG_IOB_THROTTLE=0, then CONFIG_NET_SEND_BUFSIZE needs to be restricted to be less than `CONFIG_IOB_NBUFFERS*CONFIG_IOB_BUFSIZE / The number of TCP sockets that the business may create`, can largely alleviate this problem, but since IOB may not always fully utilize all buffers, there is still a certain risk. If it is a scenario where CONFIG_IOB_THROTTLE>0, we'd better set IOB in the TX direction to throttle=true and in the RX direction to throttle=false, which is not quite consistent with the current allocation logic. If this suggestion is approved, a patch needs to be submitted to modify the IOB allocation logic accordingly. In this case, there is no need to impose overly strict restrictions on CONFIG_NET_SEND_BUFSIZE, but scenarios where the application does not read readahead for a long time still need to be avoided. Therefore, it is best to impose appropriate restriction s on CONFIG_NET_RECV_BUFSIZE, which should completely avoid the issue of the protocol stack getting stuck. > > Optimization of performance requires further specialized analysis and solution design. > > On different products, it is necessary to make reasonable configurations for CONFIG_IOB_NBUFFERS, CONFIG_IOB_BUFSIZE, CONFIG_NET_RECV_BUFSIZE, CONFIG_NET_RECV_BUFSIZE, CONFIG_IOB_THROTTLE, etc., in combination with the memory allocation situation to make the protocol stack work more efficiently and robustly. I push an enhanced patch for this scenario https://github.com/apache/nuttx/pull/18011 -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
