From: Mauro Carvalho Chehab <firstname.lastname@example.org> To: "Rémi Denis-Courmont" <email@example.com> Cc: Tomasz Stanislawski <firstname.lastname@example.org>, Laurent Pinchart <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2 Date: Fri, 20 Apr 2012 10:36:32 -0300 [thread overview] Message-ID: <4F916660.email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> Em 20-04-2012 07:56, Rémi Denis-Courmont escreveu: > On Fri, 20 Apr 2012 10:41:37 +0200, Tomasz Stanislawski > <email@example.com> wrote: >>> Am I understanding wrong or are you saying that you want to drop > userptr >>> from V4L2 API in long-term? If so, why? >> >> Dropping userptr is just some brainstorming idea. >> It was found out that userptr is not a good mean >> for buffer exchange between to two devices. > > I can believe that. But I am also inclined to believe that DMABUF is > targetted at device-to-device transfer, while USERPTR is targetted at > device-to-user (or user-to-device) transfers. Are you saying applications > should use DMABUF and memory map the buffers? Or would you care to explain > how DMABUF addresses the problem space of USERPTR? I agree with Rémi. Userptr were never meant to be used by dev2dev transfer. The overlay mode were designed for it. I remember I've pointed it a few times at the mailing list. The DMABUF is the proper replacement for the overlay mode, and, after having it fully implemented, we can deprecate and remove the overlay mode. > >> The USERPTR simplifies userspace code but introduce >> a lot of complexity problems for the kernel drivers >> and frameworks. > > It is not only a simplification. In some cases, USERPTR is the only I/O > method that supports zero copy in pretty much any circumstance. When the > user cannot reliably predict the maximum number of required buffers, > predicts a value larger than the device will negotiate, or needs buffers to > outlive STREAMOFF (?), MMAP requires memory copying. USERPTR does not. Yes, that's my understand too. USERPTR works helps to avoid buffer copying. > > Now, I do realize that some devices cannot support USERPTR efficiently, > then they should not support USERPTR. But for those devices that can, it > seems quite a nice performance enhancement. Agreed. A quick note about that: for USB devices, with the current implementations, there will always be a copy inside the Kernel, as the USB and other transport headers should be removed. For them, the cost of MMAP and USERPTR is the same (not all USB drivers export USERPTR, because of a limitation at videobuf-vmalloc). >> The problem is that memory mmaped to the userspace may >> not be a part of the system memory. It often happens for >> devices that use remap_pfn or dma_mmap_* to mmap the >> memory to the userspace. >> >> It is was empirically conjured the it is not possible >> to access this kind of memory by the other device >> without a platform-specific hacks or workarounds. As I warned in the past: USERPTR were never meant to be used for dev2dev transfers. >> >> The DMABUF was introduced to help in such a case. >> >> The basic short-term idea is to drop userptr support for >> buffers that are MMAPed by other device. You should, instead, just drop userptr support on devices where DMA scatter/gather is not supported, and migrate all dev2dev use cases to DMABUF. >> >> The userptr will be used for memory allocated using malloc >> (anonymous pages) or (maybe) mmaped files. There are of >> course cache synchronization problems but there are >> a lesser concern. >> >> However this approach will work only for devices that >> have its own IOMMU which can be configured to access system >> memory. Otherwise, the memory has to copied anyway >> to device's own buffers. >> >> Moreover copying a large amount of data should not happen >> in the kernel-space. >> >> All the reasons make userptr an unreliable and complex to >> implement feature. >> >> So my rough-idea was to remove USERPTR support from kernel >> drivers (if possible of course) and to provide an emulation >> layer in the userspace code like libv4l2. >> >> Please note that it is only a rough idea. Just brainstorming :) > It is *too early* to start any discussion on this topic. > Especially until DMABUF is mature enough to become a good > alternative for userptr. Looking at the hole picture, dropping USERPTR would only make sense if it is broken on dev2user (or user2dev) transfers. Dropping its usage on dev2dev transfers makes sense, after having DMABUF implemented. Yet, if some userspace application wants to abuse of USERPTR in order to use it for dev2dev transfer, there's not much that can be done at Kernel level. It makes sense to put a big warn at the V4L2 Docs telling that this is not officially supported and can cause all sorts of issues at the machine/system. Regards, Mauro
next prev parent reply other threads:[~2012-04-20 13:37 UTC|newest] Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-04-13 15:47 [PATCH v4 00/14] Integration of videobuf2 with dmabuf Tomasz Stanislawski 2012-04-13 15:47 ` [PATCH v4 01/14] v4l: Add DMABUF as a memory type Tomasz Stanislawski 2012-04-17 0:57 ` Laurent Pinchart 2012-04-13 15:47 ` [PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2 Tomasz Stanislawski 2012-04-16 23:25 ` Laurent Pinchart 2012-04-19 14:32 ` Tomasz Stanislawski 2012-04-19 20:36 ` Mauro Carvalho Chehab 2012-04-19 20:37 ` Mauro Carvalho Chehab 2012-04-20 8:41 ` Tomasz Stanislawski 2012-04-20 10:56 ` Rémi Denis-Courmont 2012-04-20 10:56 ` Rémi Denis-Courmont 2012-04-20 12:25 ` Tomasz Stanislawski 2012-04-20 13:03 ` Rémi Denis-Courmont 2012-04-20 13:03 ` Rémi Denis-Courmont 2012-04-21 17:10 ` Laurent Pinchart 2012-04-20 14:48 ` Mauro Carvalho Chehab 2012-04-20 13:36 ` Mauro Carvalho Chehab [this message] 2012-04-23 7:50 ` Marek Szyprowski 2012-04-23 14:00 ` Mauro Carvalho Chehab 2012-04-13 15:47 ` [PATCH v4 03/14] v4l: vb2: add support for shared buffer (dma_buf) Tomasz Stanislawski 2012-04-17 0:57 ` Laurent Pinchart 2012-04-13 15:47 ` [PATCH v4 04/14] v4l: vb: remove warnings about MEMORY_DMABUF Tomasz Stanislawski 2012-04-17 0:57 ` Laurent Pinchart 2012-04-13 15:47 ` [PATCH v4 05/14] v4l: vb2-dma-contig: Shorten vb2_dma_contig prefix to vb2_dc Tomasz Stanislawski 2012-04-13 15:47 ` [PATCH v4 06/14] v4l: vb2-dma-contig: Remove unneeded allocation context structure Tomasz Stanislawski 2012-04-17 0:57 ` Laurent Pinchart 2012-04-13 15:47 ` [PATCH v4 07/14] v4l: vb2-dma-contig: Reorder functions Tomasz Stanislawski 2012-04-13 15:47 ` [PATCH v4 08/14] v4l: vb2-dma-contig: add support for scatterlist in userptr mode Tomasz Stanislawski 2012-04-17 0:43 ` Laurent Pinchart 2012-04-17 0:43 ` Laurent Pinchart 2012-04-20 8:52 ` Tomasz Stanislawski 2012-04-13 15:47 ` [PATCH v4 09/14] v4l: vb2: add prepare/finish callbacks to allocators Tomasz Stanislawski 2012-04-17 0:57 ` Laurent Pinchart 2012-04-13 15:47 ` [PATCH v4 10/14] v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator Tomasz Stanislawski 2012-04-13 15:47 ` [PATCH v4 11/14] v4l: vb2-dma-contig: add support for dma_buf importing Tomasz Stanislawski 2012-04-17 0:57 ` Laurent Pinchart 2012-04-17 0:57 ` Laurent Pinchart 2012-04-19 11:38 ` Tomasz Stanislawski 2012-04-13 15:47 ` [PATCH v4 12/14] v4l: vb2-dma-contig: change map/unmap behaviour for importers Tomasz Stanislawski 2012-04-17 1:03 ` Laurent Pinchart 2012-04-13 15:47 ` [PATCH v4 13/14] v4l: s5p-tv: mixer: support for dmabuf importing Tomasz Stanislawski 2012-04-13 15:47 ` [PATCH v4 14/14] v4l: fimc: " Tomasz Stanislawski 2012-04-20 12:56 ` Sylwester Nawrocki
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4F916660.firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.