From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A522FC433DB for ; Thu, 18 Feb 2021 22:42:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6B42C64EB4 for ; Thu, 18 Feb 2021 22:42:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229849AbhBRWmB (ORCPT ); Thu, 18 Feb 2021 17:42:01 -0500 Received: from mga09.intel.com ([134.134.136.24]:30060 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229652AbhBRWl7 (ORCPT ); Thu, 18 Feb 2021 17:41:59 -0500 IronPort-SDR: 2LxtBTzaanOxnVzxYi2Csj7Cc6oj1qNMr5XflbzPlG5oEO1cXthnuee5pdR3WnbdqLkJPF1WNq rFwoyciTjHxg== X-IronPort-AV: E=McAfee;i="6000,8403,9899"; a="183795632" X-IronPort-AV: E=Sophos;i="5.81,187,1610438400"; d="scan'208";a="183795632" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2021 14:40:13 -0800 IronPort-SDR: mc6JN6ROJoj+0dVv6lfqxO01dy5p7T3HGwym7aEtBvygoS4w2OEMQ4EO/hU9ECxoi4tXeuKh+D 6u/4wXmx7U8g== X-IronPort-AV: E=Sophos;i="5.81,187,1610438400"; d="scan'208";a="386263740" Received: from smtp.ostc.intel.com ([10.54.29.231]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2021 14:40:12 -0800 Received: from localhost (mtg-dev.jf.intel.com [10.54.74.10]) by smtp.ostc.intel.com (Postfix) with ESMTP id 8F77E6365; Thu, 18 Feb 2021 14:40:12 -0800 (PST) Date: Thu, 18 Feb 2021 14:40:12 -0800 From: mark gross To: Jassi Brar Cc: "Alessandrelli, Daniele" , "mgross@linux.intel.com" , "dragan.cvetic@xilinx.com" , "corbet@lwn.net" , "palmerdabbelt@google.com" , "markgross@kernel.org" , "damien.lemoal@wdc.com" , "bp@suse.de" , "gregkh@linuxfoundation.org" , "paul.walmsley@sifive.com" , "arnd@arndb.de" , "shawnguo@kernel.org" , "peng.fan@nxp.com" , "robh+dt@kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v6 03/34] mailbox: vpu-ipc-mailbox: Add support for Intel VPU IPC mailbox Message-ID: <20210218224011.GA134379@linux.intel.com> Reply-To: mgross@linux.intel.com References: <20210212222304.110194-1-mgross@linux.intel.com> <20210212222304.110194-4-mgross@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 18, 2021 at 03:09:55PM -0600, Jassi Brar wrote: > On Thu, Feb 18, 2021 at 6:02 AM Alessandrelli, Daniele > 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