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: <CABb+yY2kxCjHqbBbgcPShyMA-xtcJEpzGXxqnjDAoufhidX-LQ@mail.gmail.com>
Date:   Thu, 18 Feb 2021 15:09:55 -0600
From:   Jassi Brar <jassisinghbrar@...il.com>
To:     "Alessandrelli, Daniele" <daniele.alessandrelli@...el.com>
Cc:     "mgross@...ux.intel.com" <mgross@...ux.intel.com>,
        "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

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