Asynchronous packet pool notifications

[elrafoon]

In asynchronous networking code, it would be very helpful to have a notification when packet was returned to the packet pool, and in turn it becomes possible to allocate packet from that pool, without blocking.

There are similar notifications on sockets.

I'm willing to develop the code and submit PR, but I'd like to agree on the design.

In my opinion there are at least these 2 paths:

1. add callback function and parameter to NX_PACKET_POOL structure
2. add linked list with callback functions and parameters to NX_PACKET_POOL structure

I vote for option 2, because there can be many clients interested in allocating packets from the same pool.

PS: I know I can spawn multiple threads and block on packet allocation, but I'm writing async code and this approach is not usable for me.

[fdesbiens]

Hi @elrafoon. I will discuss this with the team. I would gladly accept a PR. I will get back to you with our feedback.

[yuxinzhou5]

@elrafoon, From your description, it sounds like you don't want a thread (or threads) to block on nx_packet_allocate(). If this is the case, how do you envision the callback helping a thread (or threads) retrieve a packet from the pool without blocking? In other words, can you share with us (in pseudo code) how one may implement the callback?

[elrafoon]

Hi,

the simplest use case is a state machine implemented in one threadx thread, blocked on tx_event_flags_get, waiting for some of many possible events to occur.

I want one of those events to be POOL_NOT_EMPTY, indicating that some associated packet pool is no longer empty, and in turn nx_packet_allocate(..., NX_NO_WAIT) will succeed.

If there is a possibility to setup notification on NX_PACKET_POOL when packet is returned back to it, such an event flag could readily be emitted using tx_event_flags_set from the notification callback function.
This would require storing parameter for the function in NX_PACKET_POOL structure, i.e. void *nx_packet_pool_notification_ptr_arg.

I don't want to split the state machine into multiple threads and use blocking nx_packet_allocate, because it would increase complexity, create potential for race conditions and deadlocks, and also require additional stack space.

[yuxinzhou5]

@elrafoon, thanks for sharing with us your use case. As long as the callback doesn't block or hijack the packet, you have a good use case. Given what you described, does it make sense to go with option 1, where a centralized process decides what to do with the packet that was just released, rather than option 2, where you allow multiple threads to receive the callback and let them "fight" for the resource? :)

That being said, keep in mind that in a priority-driven system (most RTOS applications are), even if a thread gets the signal, another thread having a higher priority (by default, the IP thread is the 2nd highest priority thread in the system) may still get the packet before anyone else obtains the packet. There is no guarantee.

If you decide to go ahead, please keep this feature conditional with #ifdef.

Regards,

Yuxin