2018-07-20 14:57 GMT+03:00 Matwey V. Kornilov <matwey@xxxxxxxxxx>: > 2018-07-20 14:33 GMT+03:00 Tomasz Figa <tfiga@xxxxxxxxxxxx>: >> On Fri, Jul 20, 2018 at 8:23 PM Matwey V. Kornilov <matwey@xxxxxxxxxx> wrote: >>> >>> 2018-07-20 13:55 GMT+03:00 Tomasz Figa <tfiga@xxxxxxxxxxxx>: >>> > On Wed, Jul 18, 2018 at 5:51 AM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >>> >> >>> >> On Tue, 17 Jul 2018, Ezequiel Garcia wrote: >>> >> >>> >> > Hi Matwey, >>> >> > >>> >> > First of all, sorry for the delay. >>> >> > >>> >> > Adding Alan and Hans. Guys, do you have any feedback here? >>> >> >>> >> ... >>> >> >>> >> > > > So, what is the benefit of using consistent >>> >> > > > for these URBs, as opposed to streaming? >>> >> > > >>> >> > > I don't know, I think there is no real benefit and all we see is a >>> >> > > consequence of copy-pasta when some webcam drivers were inspired by >>> >> > > others and development priparily was going at x86 platforms. >>> >> > >>> >> > You are probably right about the copy-pasta. >>> >> > >>> >> > > It would >>> >> > > be great if somebody corrected me here. DMA Coherence is quite strong >>> >> > > property and I cannot figure out how can it help when streaming video. >>> >> > > The CPU host always reads from the buffer and never writes to. >>> >> > > Hardware perepherial always writes to and never reads from. Moreover, >>> >> > > buffer access is mutually exclusive and separated in time by Interrupt >>> >> > > fireing and URB starting (when we reuse existing URB for new request). >>> >> > > Only single one memory barrier is really required here. >>> >> > > >>> >> > >>> >> > Yeah, and not setting URB_NO_TRANSFER_DMA_MAP makes the USB core >>> >> > create DMA mappings and use the streaming API. Which makes more >>> >> > sense in hardware without hardware coherency. >>> >> >>> >> As far as I know, the _only_ advantage to using coherent DMA in this >>> >> situation is that you then do not have to pay the overhead of >>> >> constantly setting up and tearing down the streaming mappings. So it >>> >> depends very much on the platform: If coherent buffers are cached then >>> >> it's a slight win and otherwise it's a big lose. >>> > >>> > Isn't it about usb_alloc_coherent() being backed by DMA coherent API >>> > (dma_alloc_coherent/attrs()) and ending up allocating uncached (or >>> > write-combine) memory for devices with non-coherent DMAs? I'm not sure >>> >>> Yes, this is what exactly happens at armv7l platforms. >> >> Okay, thanks. So this seems to be exactly the same thing that is >> happening in the UVC driver. There is quite a bit of random accesses >> to extract some header fields and then a big memcpy into VB2 buffer to >> assemble final frame. >> >> If we don't want to pay the cost of creating and destroying the >> streaming mapping, we could map (dma_map_single()) once, set >> transfer_dma of URB and URB_NO_TRANSFER_DMA_MAP and then just >> synchronize the caches (dma_sync_single()) before submitting/after >> completing the URB. > > Thank you. Now it is becoming clearer to me. Please allow me some time > to try to sketch the implementation. I've tried to strategies: 1) Use dma_unmap and dma_map inside the handler (I suppose this is similar to how USB core does when there is no URB_NO_TRANSFER_DMA_MAP) 2) Use sync_cpu and sync_device inside the handler (and dma_map only once at memory allocation) It is interesting that dma_unmap/dma_map pair leads to the lower overhead (+1us) than sync_cpu/sync_device (+2us) at x86_64 platform. At armv7l platform using dma_unmap/dma_map leads to ~50 usec in the handler, and sync_cpu/sync_device - ~65 usec. However, I am not sure is it mandatory to call dma_sync_single_for_device for FROM_DEVICE direction? > >> >> Best regards, >> Tomasz >> > > > > -- > With best regards, > Matwey V. Kornilov. > Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia > 119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382 -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
