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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ffc9713e441389d19e7221ad4d16b938fa412361.camel@intel.com>
Date:   Thu, 18 Feb 2021 12:02:25 +0000
From:   "Alessandrelli, Daniele" <daniele.alessandrelli@...el.com>
To:     "jassisinghbrar@...il.com" <jassisinghbrar@...il.com>,
        "mgross@...ux.intel.com" <mgross@...ux.intel.com>
CC:     "dragan.cvetic@...inx.com" <dragan.cvetic@...inx.com>,
        "corbet@....net" <corbet@....net>,
        "palmerdabbelt@...gle.com" <palmerdabbelt@...gle.com>,
        "markgross@...nel.org" <markgross@...nel.org>,
        "damien.lemoal@....com" <damien.lemoal@....com>,
        "bp@...e.de" <bp@...e.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "paul.walmsley@...ive.com" <paul.walmsley@...ive.com>,
        "arnd@...db.de" <arnd@...db.de>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "peng.fan@....com" <peng.fan@....com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 03/34] mailbox: vpu-ipc-mailbox: Add support for Intel
 VPU IPC mailbox

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)