Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210212222304.110194-1-mgross@linux.intel.com>
 <20210212222304.110194-4-mgross@linux.intel.com> <CABb+yY1MLxArMY7g7HY06Tn5aABwpmUuXN9KddHZpW-_Mmu2iA@mail.gmail.com>
 <ffc9713e441389d19e7221ad4d16b938fa412361.camel@intel.com>
In-Reply-To: <ffc9713e441389d19e7221ad4d16b938fa412361.camel@intel.com>
From:   Jassi Brar <jassisinghbrar@gmail.com>
Date:   Thu, 18 Feb 2021 15:09:55 -0600
Message-ID: <CABb+yY2kxCjHqbBbgcPShyMA-xtcJEpzGXxqnjDAoufhidX-LQ@mail.gmail.com>
Subject: Re: [PATCH v6 03/34] mailbox: vpu-ipc-mailbox: Add support for Intel
 VPU IPC mailbox
To:     "Alessandrelli, Daniele" <daniele.alessandrelli@intel.com>
Cc:     "mgross@linux.intel.com" <mgross@linux.intel.com>,
        "dragan.cvetic@xilinx.com" <dragan.cvetic@xilinx.com>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "palmerdabbelt@google.com" <palmerdabbelt@google.com>,
        "markgross@kernel.org" <markgross@kernel.org>,
        "damien.lemoal@wdc.com" <damien.lemoal@wdc.com>,
        "bp@suse.de" <bp@suse.de>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
        "arnd@arndb.de" <arnd@arndb.de>,
        "shawnguo@kernel.org" <shawnguo@kernel.org>,
        "peng.fan@nxp.com" <peng.fan@nxp.com>,
        "robh+dt@kernel.org" <robh+dt@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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