Thanks Laurent! On Sat, Sep 16, 2023 at 3:37 PM Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > > Hi Fritz, > > On Fri, Sep 15, 2023 at 03:07:38PM -0700, Fritz Koenig wrote: > > Hi, > > > > Looking at the documentation[1] it states that the fd returned from > > MEDIA_IOC_REQUEST_ALLOC can be close()ed and the kernel will take care > > of making sure it is ref counted correctly. > > > > Because MEDIA_REQUEST_IOC_REINIT needs to be called on an fd before it > > can be reused, is there a performance penalty to allocating a new fd > > (with MEDIA_IOC_REQUEST_ALLOC) for every frame instead of having a > > pool of fd's that are reused, and then immediately after queuing the > > buffer, close the file descriptor? > > > > I have a proof of concept that works, but I haven't tested it for > > performance yet. > > > > It would seem that maybe there is a latency penalty because the > > MEDIA_REQUEST_IOC_REINIT is called at the end of a frame while > > MEDIA_IOC_REQUEST_ALLOC would be called at the start of a frame. > > That's up to userspace to decide, you could also call > MEDIA_IOC_REQUEST_ALLOC at the end of a frame. That would likely defeit > the point though, as you would need to put that fd in a pool to be used > later. > > Allocating a new fd isn't very expensive. The reason why the reinit > mechanism was implemented is to avoid fd allocation errors at runtime. > By pre-allocating a pool of requests and reusing them, you are > guaranteed that you will always have a request available, even if the > system runs out of fds. > This makes sense. However, I'm not sure decoding video is my highest priority if I run out of fd's ;) > > [1]: https://docs.kernel.org/userspace-api/media/mediactl/request-api.html#recycling-and-destruction > > -- > Regards, > > Laurent Pinchart
