Donny9 commented on PR #17847: URL: https://github.com/apache/nuttx/pull/17847#issuecomment-3744770648
> > How to update the owner of iob? Since iob will be exchanged between the protocol stack and the driver, the current PR only records the "allocate" information, which is far from sufficient. These pieces of information may not reflect the actual owner information. > > You’re correct, the current implementation only tracks allocation, and I wasn’t aware that ownership could change. My assumption was that copyout typically results in freeing the buffer. If you’d like to improve the PR to handle ownership changes, please feel free to do so. Yes, his flow is complex. We need to add updates for "ower" at specific locations. These locations could be within the internal APIs related to "pkt", not just the "iob" API itself. > > > In the current PR, proc/iobinfo will search for each iob. There are duplicate pieces of information. Can they be printed in the form of iob chain, so that it is more intuitive to see the organization of iob? > > Regarding proc/iobinfo, the current approach searches for each IOB individually, which does lead to duplicate information. Printing the data as an IOB chain would indeed make the structure more intuitive, but that requires significant bookkeeping to reconstruct the chains. Additionally, the procfs printf API isn’t very convenient for this. For now, I’d prefer to keep it simple since the main goal is post-mortem analysis in cases like deadlocks, where you can manually rebuild the chains and identify owners. ok，I am currently working on an optimization: removing qentry and concatenating all iob elements onto the iob queue. The end of the iob chain has a special flag to indicate it. After this optimization, it will be much easier to present this organizational structure. > > > We are also enhancing the debugging capabilities of iob internally to address issues such as iob memory leak, iob exhaustion, and iob trampling. > > Any additional tooling to improve IOB debugging would be extremely valuable. At present, IOB is quite complex and difficult to trace, which makes diagnosing issues challenging. Ideally, these problems would be addressed alongside the broader concerns in the NuttX networking stack (see #17299 and #5973). Unfortunately, I don’t have the bandwidth to work on this right now. > > Without significant improvements, the current state effectively renders the NuttX networking stack impractical for serious use, and it may be worth considering alternatives until these issues are resolved. It seems Li Auto faced similar challenges when using NuttX for its Li Auto Halo OS and ultimately decided not to use the NuttX networking stack, which is unfortunate. I am currently working on adding this feature. The internal coding has been largely completed. The main idea is to implement the native iob using Nuttx's multi-level memory pool. This allows us to reuse the trace functionality of the memory pool, including PID and backtrace. Additionally, we can protect the iob using KASAN and monitor memory overflows. I will submit it around **next week**. At that time, please provide your review suggestions based on my patch. We can compare your current implementation and collectively assess which solution is the best. The overall aim is to enable faster identification of the iob issue. @PetervdPerk-NXP -- 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]
