On Thu, Feb 18, 2021 at 6:02 AM Alessandrelli, Daniele <[email protected]> wrote: > > Hi Jassi, > > Thank you very much for your feedback. > > On Sun, 2021-02-14 at 22:54 -0600, Jassi Brar wrote: > > IIUIC, maybe the solution is simpler .... What if we set txdone_poll. > > Always return success in send_data(). And check if we overflew the > > fifo in last_tx_done(). If we did overflow, try to rewrite the data > > and check again. Return true, if not overflew this time, otherwise > > return false so that mailbox api can ask us to try again in next > > last_tx_done(). This way we can do away with the tasklet and, more > > importantly, avoid send_data() failures and retries on clients' part. > > That's a clever solution to avoid the tasklet. The only issue for us is > the automatic TX retry from the controller. I understand that's > generally a desirable feature, but in our case we'd like the client to > have full control on re-transmission attempts. > > That's because some of our data is time-sensitive. For instance, when > we process frames from a video stream we prefer dropping a frame rather > than re-transmitting it and delaying the processing of the rest. > > Now, I understand that the client can set the 'tx_block' and 'tx_tout' > channel fields to specify how long it wishes to wait, but the problem > is that our (single) channel is shared between multiple applications > having different timing requirements. That's why we prefer to let > applications deal we re-transmissions. > > Given the above, do you think it's reasonable to leave the > implementation as it is now? > (from initial analysis, the tasklet doesn't seem to affect the > performance of our use cases significantly, so we are fine with it) > Yup. It is intel specific so, hopefully, we don't have to deal with other vendors trying to support their use cases. Are you targeting the next merge window or this one?
cheers.
