Hi, Jassi, Thanks for the review! On 10/18/24 5:17 AM, Jassi Brar wrote: > On Thu, Oct 17, 2024 at 11:36 AM Tudor Ambarus <tudor.ambarus@xxxxxxxxxx> wrote: >> >> Current form of the mailbox framework doesn't allow controllers to benefit >> of their hardware queue capabilities as the framework handles a single >> active request at a time. >> >> The active request is considered completed when TX completes. But it seems >> that TX is not in direct relation with RX, >> > Correct, and it is not meant to be. > You are assuming there is always an RX in response to a TX, which is Not really. If there's no response expected, clients can set req->rx to NULL. Then the controllers know that no response is expected and can complete the request when TX completes. > not the case. Many platforms just send a message and only need to know > when it is sent. Many platforms only listen for incoming messages. these 2 cases are covered with the req approach. > Many platforms have TX and RX but not as parts of one exchange. In I don't think I understand this case. Is it related to what you describe below? > fact, only minority of platforms expect RX after each TX. Btw, what if Right, I noticed. > some platform sends only and always after each receive? For these This case is covered as well with the req approach. One just needs to serialize the requests: ret = mbox_send_request(dc->mbox_chan, req1); ret = mbox_wait_request(ret, req1->wait); if (ret) return ret; // req1 completed, send req2 ret = mbox_send_request(dc->mbox_chan, req2); ret = mbox_wait_request(ret, req2->wait); if (ret) return ret; This shall work regardless if the client expects a response or not. If no response is expected, but just a TX completion, then the client can set req->rx = NULL. > reasons, it is left to the user to tie an incoming RX to some previous > TX, or not. It's possible I haven't covered all the cases, but I'm willing to understand them and come up with a new version with your help, where I address all the concerns. Cheers, ta
