From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932256AbeCLMVX (ORCPT ); Mon, 12 Mar 2018 08:21:23 -0400 Received: from mail-lf0-f68.google.com ([209.85.215.68]:45027 "EHLO mail-lf0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932217AbeCLMVT (ORCPT ); Mon, 12 Mar 2018 08:21:19 -0400 X-Google-Smtp-Source: AG47ELs25Sw8Zb0aVlFSIIS3KVcenFVcl8hlu2cAlArzItl/82Z5M/FgurmJtpRGlE+1gbd6S52Nxw== Subject: Re: [RFCv4,19/21] media: vim2m: add request support To: Tomasz Figa , Paul Kocialkowski Cc: Alexandre Courbot , Mauro Carvalho Chehab , Hans Verkuil , Laurent Pinchart , Pawel Osciak , Marek Szyprowski , Sakari Ailus , Gustavo Padovan , Linux Media Mailing List , Linux Kernel Mailing List , Maxime Ripard References: <20180220044425.169493-20-acourbot@chromium.org> <1520440654.1092.15.camel@bootlin.com> <6470b45d-e9dc-0a22-febc-cd18ae1092be@gmail.com> <1520842245.1513.5.camel@bootlin.com> <1520843103.1513.8.camel@bootlin.com> From: Dmitry Osipenko Message-ID: <85a6fdc4-e01c-c6e4-d027-dea161e5b90e@gmail.com> Date: Mon, 12 Mar 2018 15:21:16 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12.03.2018 11:29, Tomasz Figa wrote: > On Mon, Mar 12, 2018 at 5:25 PM, Paul Kocialkowski > wrote: >> Hi, >> >> On Mon, 2018-03-12 at 17:15 +0900, Tomasz Figa wrote: >>> Hi Paul, Dmitry, >>> >>> On Mon, Mar 12, 2018 at 5:10 PM, Paul Kocialkowski >>> wrote: >>>> Hi, >>>> >>>> On Sun, 2018-03-11 at 22:42 +0300, Dmitry Osipenko wrote: >>>>> Hello, >>>>> >>>>> On 07.03.2018 19:37, Paul Kocialkowski wrote: >>>>>> Hi, >>>>>> >>>>>> First off, I'd like to take the occasion to say thank-you for >>>>>> your >>>>>> work. >>>>>> This is a major piece of plumbing that is required for me to add >>>>>> support >>>>>> for the Allwinner CedarX VPU hardware in upstream Linux. Other >>>>>> drivers, >>>>>> such as tegra-vde (that was recently merged in staging) are also >>>>>> badly >>>>>> in need of this API. >>>>> >>>>> Certainly it would be good to have a common UAPI. Yet I haven't >>>>> got my >>>>> hands on >>>>> trying to implement the V4L interface for the tegra-vde driver, >>>>> but >>>>> I've taken a >>>>> look at Cedrus driver and for now I've one question: >>>>> >>>>> Would it be possible (or maybe already is) to have a single IOCTL >>>>> that >>>>> takes input/output buffers with codec parameters, processes the >>>>> request(s) and returns to userspace when everything is done? >>>>> Having 5 >>>>> context switches for a single frame decode (like Cedrus VAAPI >>>>> driver >>>>> does) looks like a bit of overhead. >>>> >>>> The V4L2 interface exposes ioctls for differents actions and I don't >>>> think there's a combined ioctl for this. The request API was >>>> introduced >>>> precisely because we need to have consistency between the various >>>> ioctls >>>> needed for each frame. Maybe one single (atomic) ioctl would have >>>> worked >>>> too, but that's apparently not how the V4L2 API was designed. >>>> >>>> I don't think there is any particular overhead caused by having n >>>> ioctls >>>> instead of a single one. At least that would be very surprising >>>> IMHO. >>> >>> Well, there is small syscall overhead, which normally shouldn't be >>> very painful, although with all the speculative execution hardening, >>> can't be sure of anything anymore. :) >> >> Oh, my mistake then, I had it in mind that it is not really something >> noticeable. Hopefully, it won't be a limiting factor in our cases. > > With typical frame rates achievable by hardware codecs, I doubt that > it would be a limiting factor. We're using a similar API (a WiP > version of pre-Request API prototype from long ago) in Chrome OS > already without any performance issues. Thank you very much for the answers! The syscalls overhead is miserable in comparison to the rest of decoding, though I wanted to clarify whether there is a way to avoid it. Atomic API sounds like something that would suit well for that.