Attention is currently required from: jolly, pespin.
laforge has posted comments on this change by jolly. (
https://gerrit.osmocom.org/c/libosmocore/+/40725?usp=email )
Change subject: Automatically increase io_uring, if too small.
......................................................................
Patch Set 2:
(1 comment)
Patchset:
PS2:
IMHO this shouldn't happen if we use a big-enough
ring size. […]
this was based on a discussion aeversberg and I had before he started
to wrok on the patch. The overflowing ring can happen with a lot of FDs that have so far
one pending read-sqe, and which now might each have multiple sqe's each.
The application has no idea of the total number of fd's encountered during runtime.
The library has even less of an idea. The sysadmin/operator might be able to estimate it,
*if* they really understand a lot about the overall architecture and the need to
statically size the SQE array. I'd argue 99% of the people operating our software
might not be aware of such a requirement. So we should scale automatically, if needed.
Delaying a write will happen automatically via a queue. But if we cannot allocate a sqe
for a read, how should we handle this via queueing? And as reads and writes share the
same ring (and hence pool of SQE), we cannot prioritize reads over writes.
What is wrong about creating a new (larger) ring when detecting the current one is too
small? That should be a super-rare event maybe once or so if load increases a lot.
Afterwards the size is sufficient for future similar load scenarios during process
runtime.
--
To view, visit
https://gerrit.osmocom.org/c/libosmocore/+/40725?usp=email
To unsubscribe, or for help writing mail filters, visit
https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: Id9230146acc8d54bfd44834e783c31b37bd64bca
Gerrit-Change-Number: 40725
Gerrit-PatchSet: 2
Gerrit-Owner: jolly <andreas(a)eversberg.eu>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: jolly <andreas(a)eversberg.eu>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Wed, 23 Jul 2025 08:36:58 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>