Re: [PATCH v6 03/34] mailbox: vpu-ipc-mailbox: Add support for Intel VPU IPC mailbox

[Jassi Brar]

On Thu, Feb 18, 2021 at 6:02 AM Alessandrelli, Daniele
<daniele.alessandrelli@xxxxxxxxx> 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.