From: Ali Nasrolahi <a.nasrolahi01@gmail.com>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Hans Verkuil <hverkuil+cisco@kernel.org>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
mchehab@kernel.org
Subject: Re: [RFC] Discussion: VIDEO_NUM_DEVICES limit in v4l2-dev.c
Date: Sun, 2 Aug 2026 21:55:58 +0330 [thread overview]
Message-ID: <am-KtTBaHCshGpeb@zephyr> (raw)
In-Reply-To: <20260802125734.198631b5@foz.lan>
On 26/08/02 12:57PM, Mauro Carvalho Chehab wrote:
> On Sun, 2 Aug 2026 08:24:29 +0330
> Ali Nasrolahi <a.nasrolahi01@gmail.com> wrote:
> > I'm working on a project involving high density video processing on a
> > single server using a large number of v4l2 loopback devices to route
> > virtual video streams to tenants.
> >
> > While doing so, I ran into the hard limit imposed by `VIDEO_NUM_DEVICES`
> > (currently 256) in `drivers/media/v4l2-core/v4l2-dev.c`. Looking through
> > the code and git history, this limit has been there for quite a long time.
> > However, after searching the mailing list archives, I couldn't find any
> > previous discussion regarding this limitation.
> >
> > May I ask:
> >
> > 1. Is there any internal design constraint that requires limiting the
> > number of V4L2 devices to 256 on modern kernels?
>
> There was a constraint at the very beginning due to the way minors
> were generated. If I'm not mistaken, this was long gone.
>
> Still, having a maximum limit is desirable as there is a hard limit
> in terms of the memory.
>
> > 2. Has this limit been discussed previously, or is there any relevant
> > discussion that I may have missed?
>
> Probably, but likely very years ago. I can't recall last time we
> discussed this particular limit.
>
> > If the current limit is no longer intentional and there's no historical
> > context that I might've missed, I'd be happy to work on a patch series to
> > address it, and I would appreciate any guidance on the preferred direction.
>
> What is the maximum limit your hardware has? Can you provide some
> documentation related to it?
Assuming I understood your question correctly, because the workloads run
on a server, theoretically, there is no fixed limit on the number of
virtual video devices that could be used. As long as there is enough cpu
power, memory, and i/o bandwidth available, it is beneficial to be able
to add devices and, consequently, run more workloads.
That being said, to give some rough numbers, I think supporting at least
1000 to 2000 devices would likely cover most practical cases.
This is why I was wondering whether making this limit dynamically
allocated or at least configurable might be beneficial, so, for example,
mahcines with limited memory would not have to reserve an unnecessarily
large array, while systems with more resources could scale accordingly.
For some additional context, the video streams are received over the
network from various sources such as cameras and WebRTC. These streams
are then routed to v4l2loopback devices, which are used by the workloads
for processing.
Regards,
-Ali
next prev parent reply other threads:[~2026-08-02 18:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-02 4:54 [RFC] Discussion: VIDEO_NUM_DEVICES limit in v4l2-dev.c Ali Nasrolahi
2026-08-02 10:57 ` Mauro Carvalho Chehab
2026-08-02 18:25 ` Ali Nasrolahi [this message]
2026-08-03 7:04 ` Hans Verkuil
2026-08-03 17:56 ` Ali Nasrolahi
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=am-KtTBaHCshGpeb@zephyr \
--to=a.nasrolahi01@gmail.com \
--cc=hverkuil+cisco@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab+huawei@kernel.org \
--cc=mchehab@kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.