linux-kernel - Re: [RFCv4,19/21] media: vim2m: add request support

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: <CAPBb6MXYj0SHUWPRuCNewUetmxrePx1NFQfB6tw+BbPHS+Hkmg@mail.gmail.com>
Date:   Mon, 12 Mar 2018 21:32:42 +0900
From:   Alexandre Courbot <acourbot@...omium.org>
To:     Tomasz Figa <tfiga@...omium.org>
Cc:     Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
        Dmitry Osipenko <digetx@...il.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Hans Verkuil <hverkuil@...all.nl>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Pawel Osciak <posciak@...omium.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Gustavo Padovan <gustavo.padovan@...labora.com>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Maxime Ripard <maxime.ripard@...tlin.com>
Subject: Re: [RFCv4,19/21] media: vim2m: add request support

On Mon, Mar 12, 2018 at 5:15 PM, Tomasz Figa <tfiga@...omium.org> wrote:
> Hi Paul, Dmitry,
>
> On Mon, Mar 12, 2018 at 5:10 PM, Paul Kocialkowski
> <paul.kocialkowski@...tlin.com> 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. :)
>
> Hans and Alex can correct me if I'm wrong, but I believe there is a
> more atomic-like API being planned, which would only need one IOCTL to
> do everything. However, that would be a more serious change to the
> V4L2 interfaces, so should be decoupled from Request API itself.

Indeed, we discussed the possibility to setup and submit requests in
one syscall, similarly (at least in spirit) to the DRM atomic API.

This has only been discussed though, and as a feature to consider
*after* the request API is merged for codecs (as the more complex
camera use-cases would benefit more from it). As Tomasz mentioned, the
overhead of ioctls is somehow negligible compared to the workload of
the encoding/decoding itself, although I suppose it can still add up.
The main advantage I can see for this is a simpler and less
error-prone setup of requests for user-space.