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 <andr...@eversberg.eu> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <lafo...@osmocom.org> Gerrit-CC: pespin <pes...@sysmocom.de> Gerrit-Attention: jolly <andr...@eversberg.eu> Gerrit-Attention: pespin <pes...@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 <pes...@sysmocom.de>
