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: <20210218224011.GA134379@linux.intel.com>
Date:   Thu, 18 Feb 2021 14:40:12 -0800
From:   mark gross <mgross@...ux.intel.com>
To:     Jassi Brar <jassisinghbrar@...il.com>
Cc:     "Alessandrelli, Daniele" <daniele.alessandrelli@...el.com>,
        "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 03:09:55PM -0600, Jassi Brar wrote:
> 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?
>

Its a bit late for the v5.12 merge window for most of the code in this patchset
at this point but, if you feel like getting this inital bit in that would be
great.

I'm hoping we can get the rest of this series into linux-next after RC1.

--mark