https://osmocom.org/https://osmocom.org/favicon.ico?16647414092022-11-09T12:29:14ZOpen Source Mobile Communicationslibosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=253332022-11-09T12:29:14Zlaforge
<ul></ul><p>I'd like the idea of splitting tihs into two separate sub-tasks:</p>
<ol>
<li>introduce the conceptual API changes of having the actual read/write done inside libosmocore; then start to port applications over to that new API</li>
<li>subsequently (and fully optionally) introduce an io_uring backend to libosmocore so it can benefit from the related performance improvements.</li>
</ol>
<p>By splitting this is up into two parts, we can more easily pinpoint any related problems, as we can test one part without the other.</p>
<p>Furthermore, on any older systems that don't have kernels with io_uring support, we can simply not use it, as the second step is independent of the first step. The applications simply always use the same API, whether or not libosmocore uses io_uring becomes an implementation detail unknown to the applications.</p> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=253342022-11-09T12:38:35Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-4 priority-high2 closed" href="/issues/5752">Feature #5752</a>: io_uring support in libosmo-sigtran</i> added</li></ul> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=253372022-11-09T12:43:46Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-3 priority-high3 closed" href="/issues/5753">Feature #5753</a>: io_uring support in libosmo-netif</i> added</li></ul> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=253412022-11-09T12:45:27Zlaforge
<ul><li><strong>Tags</strong> set to <i>io_uring</i></li></ul> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=253422022-11-09T12:48:31Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-3 priority-high3 closed" href="/issues/5754">Feature #5754</a>: io_uring support in libosmo-mgcp-client</i> added</li></ul> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=253442022-11-09T12:57:04Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-2 priority-3 priority-high3" href="/issues/5755">Feature #5755</a>: io_uring support in osmo-bsc</i> added</li></ul> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=253472022-11-09T13:02:09Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-1 priority-2 priority-default" href="/issues/5756">Bug #5756</a>: io_uring support in libosmo-abis</i> added</li></ul> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=253492022-11-09T13:17:48Zlaforge
<ul></ul><p>for some existing example how to use io_uring in the osmocom context, check out rtp-load-gen at <a class="external" href="https://gitea.osmocom.org/cellular-infrastructure/osmo-mgw/src/branch/laforge/rtp-load-gen/contrib/rtp-load-gen">https://gitea.osmocom.org/cellular-infrastructure/osmo-mgw/src/branch/laforge/rtp-load-gen/contrib/rtp-load-gen</a> and grep for io_uring_ showing the various API calls. There's also <a class="external" href="https://gitea.osmocom.org/cellular-infrastructure/gtp-load-gen">https://gitea.osmocom.org/cellular-infrastructure/gtp-load-gen</a></p>
<ul>
<li><code>io_uring_get_sqe</code> returns an unused submission queue entry</li>
<li><code>io_uring_prep_write</code> and <code>io_uring_prep_write</code> fills that submission queue entry with a fd, pointer to data + length</li>
<li><code>io_uring_submit</code> submits whatever prepared submission queue entries</li>
</ul>
also see:
<ul>
<li>io_uring tutorial at <a class="external" href="https://unixism.net/loti/tutorial/index.html">https://unixism.net/loti/tutorial/index.html</a></li>
<li>liburing code at <a class="external" href="https://github.com/axboe/liburing">https://github.com/axboe/liburing</a></li>
</ul>
<p>The libosmocore integration with the existing select/poll would likely be done via an eventfd. So applications will continue to use osmo_select_main() etc. and can use any number of their file descriptors as they did so far. But libosmocore will internally register an eventfd with the existing select/poll API, so that any time io_uring wants to notify us about completions, it marks that eventfd as readable, triggering our select/poll loop to handle those completion events. So why is this faster? Because there will be one such eventfd-poll-trigger for a virtually unlimited number of io_uring completion events, as opposed to one poll+read/write syscall for each of them.</p> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=253502022-11-09T13:58:54ZHoernchen
<ul></ul><p>Please keep in mind that IORING_REGISTER_IOWQ_AFF is a fairly recent feature, so unless that exists "automatically" turning on uring support, if available, leads to a bunch of theads ( as for the number and other details: <a class="external" href="https://blog.cloudflare.com/missing-manuals-io_uring-worker-pool/">https://blog.cloudflare.com/missing-manuals-io_uring-worker-pool/</a> is worth a read) that just end up somewhere, without easy ways to move those to a specific cpu.</p> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=253512022-11-09T14:45:09Zlaforge
<ul></ul><p>On Wed, Nov 09, 2022 at 01:58:54PM +0000, Hoernchen wrote:</p>
<blockquote>
<p>Please keep in mind that IORING_REGISTER_IOWQ_AFF is a fairly recent feature, so unless that exists "automatically" turning on uring support, if available, leads to a bunch of theads ( as for the number and other details: <a class="external" href="https://blog.cloudflare.com/missing-manuals-io_uring-worker-pool/">https://blog.cloudflare.com/missing-manuals-io_uring-worker-pool/</a> is worth a read) that just end up somewhere, without easy ways to move those to a specific cpu.</p>
</blockquote>
<p>AFAICT there are no kernel threads created for socket read/write, as sockets support non-blocking operation.</p>
<p>99.9% of all I/O we are doing is on sockets (UDP, TCP, SCTP, Unix) for talking to other network elements or<br />the user via VTY/CTRL. There is a bit of file I/O when reading config files (not worth optimzing anyway) and from osmo-hlr / osmo-msc for the respective database, which is accessed in blocking I/O anyway.</p> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=253722022-11-13T07:26:14Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-1 priority-1 priority-lowest" href="/issues/5766">Feature #5766</a>: use Linux kernel KCM for IPA header?</i> added</li></ul> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=254612022-11-18T12:59:26Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>laforge</i> to <i>daniel</i></li></ul><p>Update: I've been playing for a few days with some of the concepts and trying to bring all our requirements in-line toward the first step (new API that can support poll and later io_uring backend).</p>
<p>I've handed this over to <a class="user active" href="https://osmocom.org/users/30">daniel</a> now as he has more time available right now and indicated an interest in this topic. We just had a call where I explained my thoughts and the latest results how I think it shuold all be put together.</p>
<p>I'm of course available whenever feedback/questions arise.</p> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=254642022-11-18T16:47:50Zlaforge
<ul></ul><p>summary of some of my ideas / thoughts on the new <em>I/O provider</em> so far:</p>
<ul>
<li><strong>modes</strong>. The new I/O provider will need to offer the following modes:
<ul>
<li>read/write (e.g. tcp sockets for IPA OML/RSL/GSUP as well as CBSP, VTY, CTRL, ...)</li>
<li>recvfrom/sendto (e.g. UDP sockets used for RTP, GTP, MGCP, ...)
<ul>
<li>io_uring doesn't directly support those syscalls. However, it does support recvmsg/sendmsg, which is a superset of recfrom/sendto combined with readv/writev</li>
<li>we have to convert recfrom/sendto by API users (applications) to recvmsg/sendmsg</li>
</ul>
</li>
<li>sctp_recvfrom/sctp_sendto (SCTP sockets for anything M3UA/SUA/sigtran)
<ul>
<li>this API from libsctp is just a 20-line wrapper around normal recvmsg/sendmsg calls</li>
<li>we have to re-implement this wrapper in our io_uring code</li>
</ul>
</li>
</ul>
</li>
<li>introduction of a new <code>struct osmo_io_fd</code> which will be used instead of <code>osmo_fd</code>, containing
<ul>
<li>fd</li>
<li><code>const char *name</code> for application to provide a human-readable name of the FD (in case I/O provider wants to log something)</li>
<li>parameters for msgb_alloc (headroom, context, size)</li>
<li>a built-in write-queue with semantics like osmo_wqueue</li>
<li>call-back functions for the user application (read/write completion call-backs)</li>
<li>priv/priv_nr for context of application (like osmo_fd)</li>
</ul>
</li>
<li>write operation
<ul>
<li>application does something like <code>osmo_io_write(struct osmo_io_fd *, struct msgb *)</code></li>
<li>I/O provider enqueues any write into write queue and marks FD as "wants to write" </li>
<li>io_uring backend
<ul>
<li>would check if write is pending completion. If not, submit first entry of write_queue to io_uring</li>
<li>at some later point, I/O provider io_uring backend is notified via osmo_fd-wapped-eventfd that io_uring has completed something</li>
<li>once I/O provider io_uring backend identifies a write has completed, it will call the <code>io_fd->write_cb(struct osmo_io_fd *fd, int rc, struct msgb *msg)</code> call-back</li>
</ul>
</li>
<li>classic poll backend
<ul>
<li>would now check if OSMO_FD_WRITE is active. If not, set it.</li>
<li>gets notified that osmo_fd is writable</li>
<li>issues normal non-blocking <code>write()</code> syscall</li>
<li>call the <code>io_fd->write_cb(struct osmo_io_fd *fd, int rc, struct msgb *msg)</code> call-back</li>
</ul>
</li>
<li>the application can now act basd on rc (short write, negative error, dead socket, etc)</li>
<li>once call-back returns, I/O provider does <code>msgb_free(msg)</code></li>
</ul>
</li>
<li>read operation
<ul>
<li>application notifies I/O provider that it wants to read from <code>osmo_io_fd</code></li>
<li>io_uring backend
<ul>
<li>allocates a msgb (using parameters provided by application stored in <code>osmo_io_fd</code></li>
<li>submits a <code>read()</code> syscall to io_uring submission queue pointing to msgb memory</li>
<li>completion is handled just like the write completion via osmo_fd-wrapped-eventfd</li>
<li><code>io_fd->read_cb(struct osmo_io_fd *fd, int rc, struct msgb *msg)</code> is called</li>
</ul>
</li>
<li>classic poll backend
<ul>
<li>enables <code>OSMO_FD_READ</code> on socket</li>
<li>gets notified that osmo_fd is readable once data is available</li>
<li>allocates a msgb (using parameters provided by application stored in <code>osmo_io_fd</code></li>
<li>issues normal non-blocking <code>read()</code> syscall</li>
<li><code>io_fd->read_cb(struct osmo_io_fd *fd, int rc, struct msgb *msg)</code> is called</li>
</ul></li>
</ul></li>
</ul> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=254662022-11-18T16:55:52Zlaforge
<ul></ul><p>For the <code>{send,recv}{to,from,msg}()</code> family of calls, we need to extend the above slightly. In addition the raw msgb, we have metadata like the <code>struct sockaddr</code> to send to.</p>
<p>I originally thought we could push this to the front of the msgb headroom, but sockaddr_storage is already 128 bytes plus the <code>struct msghdr</code> <code>struct iovec</code> etc. quickly adds up to something like 200 bytes. Since msgb size (including headroom) is limited to 16bit (historical mistake), I'm not sure if it's the right way.</p>
<p>I then decided to go for a <code>struct serialized_msghdr</code> which we allocate at the time the user issues e.g. a <code>osmo_io_sendto(struct osmo_io_fd *, struct msgb *msg, int flags, const struct sockaddr *dest_addr, socklen_t addrlen)</code> call. The function would then copy the provided parameters into that heap-allocated <code>serialized_msghdr</code>, and enqueue that (instead of the pure msg) into the in-memory transmit queue. Once the actual <code>sendmsg</code> call is performed (async via io_uring or directly via syscall), we dequeue that msghdr and make use of it. On completion we call the user completion call-back and then free the <code>serialized_msghdr</code> as well as the msgb afterwards.</p>
<p>The same approach also works for the <code>recvmsg/recvffrom</code> case, where we can have an application call-back like <code>void (*recvfrom_cb)(struct osmo_io_fd *iofd, int rc, struct msgb *msg, struct sockaddr *src_addr, socklen_t *addrlen);</code></p>
<p>Equally this approach works for <code>sctp_sendmsg/sctp_recvmsg</code> as those are just wrappers with different function arguments that all get encoded into a <code>struct msghdr</code>.</p> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=254792022-11-19T09:26:06Zlaforge
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Urgent</i></li></ul> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=255282022-11-22T14:49:43Zdaniel
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=257222022-12-06T14:31:39Zdaniel
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>30</i></li></ul><p>An update on the io_uring osmo_io progress so far:<br />The WIP commits are in libosmocore.git branch daniel/io_uring.<br /><a class="external" href="https://gitea.osmocom.org/osmocom/libosmocore/src/branch/daniel/io_uring">https://gitea.osmocom.org/osmocom/libosmocore/src/branch/daniel/io_uring</a></p>
<a name="Whats-done"></a>
<h3 >What's done<a href="#Whats-done" class="wiki-anchor">¶</a></h3>
<p>I managed to get a basic version of osmo_io working with the poll backend and have also working backend for io_uring.</p>
<p>With it the NS2 UDP socket used osmo_io in with sendto()/recvfrom(). The control interface is also using osmo_io complete with IPA parsing/segmentation (with read()/write() mode).</p>
<p>With this the ttcn3 osmo-gbproxy tests (which also uses the ctrl_if) as well as make distcheck pass.</p>
<p>libosmocore currently tries to build with uring support unless passed `--disable-uring` during configure. The default will be io_uring if it's enabled.<br />The environment variable `LIBOSMO_IO_BACKEND` can be used to switch backends at runtime. Setting it to something other than "IO_URING" will use the poll/osmo_fd backend. This can be verified by setting the new DIO loglevel to DEBUG and watching for the message:<br />"iofd(<name>) using backend poll/uring"</p>
<a name="Open-issues"></a>
<h3 >Open issues<a href="#Open-issues" class="wiki-anchor">¶</a></h3>
<ul>
<li>Porting over the ipa.c/ipaccess.c code in libosmo-abis will be a significant amount of work since quite a few functions get direct access to an osmo_fd of even a plain fd. They then write()/send() directly to those which will need to move to a tx queue-aware model.</li>
<li>libosmo-netif has some similar issues in its ipa code, but in general looks much better because the osmo_stream api already uses a tx_queue internally and matches the callback api of osmo_io much better.</li>
<li>sctp support is not implemented in osmo_io yet. This will be a wrapper around send/recvmsg, so shouldn't be too complicated.</li>
</ul>
<a name="API-notes"></a>
<h3 >API notes<a href="#API-notes" class="wiki-anchor">¶</a></h3>
<p>The osmo_io api currently has a _setup function that takes and registers a plain fd and returns a newly allocated struct osmo_io_fd *. This worked ok for ctrl_if and gprs_ns2, but I noticed in a couple places in libosmo-abis that the osmo_fd struct (with callbacks, data, ...) is initialized in one part of the code with the fd set to -1 and only registered in another when the fd is actually present.</p>
<p>Right now the osmo_io assumes that the fd is configured/connected/... correctly and will not do anything there except try to read/write from it. This should be ok for now and you can always get the raw fd and do some get/setsockopts on there.</p> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=263832023-03-20T08:59:23Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-6 priority-1 priority-lowest closed" href="/issues/5948">Bug #5948</a>: Fix socket (-write) functions in multiple projects (by moving them to a common library...)</i> added</li></ul> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=263852023-03-20T09:03:02Zlaforge
<ul><li><strong>Priority</strong> changed from <i>Urgent</i> to <i>Immediate</i></li></ul><p>This ticket is in need of updates for months. The branch has not seen any commits since early December. Yet from spoken status reports I know there has been more recent activity.</p>
<p>Please make sure to update the relevant tickets and keep pushing the current branches, thanks.</p> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=267872023-04-27T16:29:14Zpespin
<ul></ul><p>In order to push this forward a bit while <a class="user active" href="https://osmocom.org/users/30">daniel</a> is not available, I tooked over his patches (libosmocore.git daniel/io_uring), rebased and fixed/improved several things, submitted to gerrit and they are now available in branch "pespin/io_uring".</p> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=276522023-08-25T11:56:12Zosmith
<ul><li><strong>% Done</strong> changed from <i>30</i> to <i>40</i></li></ul><p>The patch has been merged to master:<br /><a class="external" href="https://gerrit.osmocom.org/c/libosmocore/+/32536">https://gerrit.osmocom.org/c/libosmocore/+/32536</a></p>
<p>I've adjusted infrastructure to fix failing builds related to the new liburing dependency:<br /><a class="external" href="https://gerrit.osmocom.org/q/topic:osmo-io+author:osmith%2540sysmocom.de+-is:merged">https://gerrit.osmocom.org/q/topic:osmo-io+author:osmith%2540sysmocom.de+-is:merged</a></p> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=285542023-11-18T17:17:11Zlaforge
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' disabled> <i>sctp support in osmo_io</i> added</li><li><strong>Assignee</strong> changed from <i>daniel</i> to <i>laforge</i></li></ul><p>regarding the high-level aspects of SCTP support, see some updates in <a class="issue tracker-2 status-3 priority-4 priority-high2 closed" title="Feature: io_uring support in libosmo-sigtran (Resolved)" href="https://osmocom.org/issues/5752#note-9">#5752#note-9</a></p>
<p>One of the unexpected problems is that msgb_sctp_{ppid,stream} is definted in libosmo-netif and hence is not available in libosmocore. We hence cannot use those existing definitions to pass parameters around in msgb :/ - and as usual, moving stuff between libraries is hard as it might break users and lead to duplicate definitions, etc.</p> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=290142024-01-10T13:44:51Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>laforge</i> to <i>Hoernchen</i></li></ul><p>My latest WIP codde is in <code>laforge/osmo_io_sctp</code> branch of libosmocore.</p>
<p>As far as I recall, one of the last problems I saw was that the well-known mechanism for non-blocking connect (mark FD as want-to-write, then call connect(), poll/select will mark socket as write-able) did not work with SCTP and io_uring. It did work for TCP sockets, but not for SCTP.</p>
<p>So as a result, we likely need some kind of work-around where we first bypass io_uring and simply use the normal select/poll code until the socket is connected, and only then start to use io_uring after the connect phase is completed.</p> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=290182024-01-10T13:59:29Zlaforge
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' disabled> <i>port vty over to osmo_io</i> added</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' disabled> <i>port ctrl over to osmo_io</i> added</li></ul> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=292162024-02-06T10:42:12Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>Hoernchen</i> to <i>jolly</i></li></ul> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=292492024-02-09T16:02:49Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-3 priority-high3 closed" href="/issues/6357">Feature #6357</a>: run (some?) tests with io_uring backend for osmo_io</i> added</li></ul> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=292562024-02-09T16:19:35Zlaforge
<ul></ul><a name="stats_reporter"></a>
<h2 >stats_reporter<a href="#stats_reporter" class="wiki-anchor">¶</a></h2>
<p>I briefly looked at migrating the osmo_stats_reporter over to osmo_io, and I'm not entirely sure if it's that great an idea. Right now each stats_reporter has one msgb that's allocated at socket-open time. Whenever there's something to write, that buffer is used and then immediately sent off using <code>sendto()</code>. There's no integration into the osmocom select loop. We always assume the [udp] socket is writable. The buffers are hence never free'd or re-allocated at runtime.</p>
<p>If we switch over to osmo_io, then it would mean every stats report allocates a new msgb, and once that's handed over to the io_uring backend there are even more allocations. So yes, we'd save the sendto system call, but at the cost of more load on the heap allocator. The syscall is likely more expensive, sure. But is it worth it? I'm not so sure.</p>
<a name="ctrl"></a>
<h2 >ctrl<a href="#ctrl" class="wiki-anchor">¶</a></h2>
<p>that should be fairly trivial to mogirate over. It uses a tx_queue anyway for writes today, so handing those msgb's over to osmo_io should be easy.</p>
<a name="vty"></a>
<h2 >vty<a href="#vty" class="wiki-anchor">¶</a></h2>
<p>The VTY uses its 'buffer' layer between writes by the software and writing to the acutal socket file descriptor. <code>buffer_flush_all</code> is currently used whenever the socket is write-able. So it's a pull model.</p>
<p>We'd probably have to change that logic to work the other way around: Once a buffer has a certain fill-level (or age?), proactively push it via osmo_io.</p>
<p>Unless somebody uses a lot of scripts acccessing the VTY, it's also unlikely that the syscall load of a human VTY user would place significant I/O load on an osmocom program. So it's not super criticial.</p> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=292992024-02-15T13:37:52Zjolly
<ul><li><strong>% Done</strong> changed from <i>40</i> to <i>70</i></li></ul><p>Patches are in Gerrit as 'WIP' with topic osmo_io_uring. Same with libosmo-netif.</p> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=294562024-03-02T09:23:35Zlaforge
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>sctp support in osmo_io</i> set to Done</li></ul> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=294572024-03-02T09:25:14Zlaforge
<ul></ul><p>SCTP support (indirectly, by sendmsg/recvmsg support) for osmo_io is in libosmocore since Change-Id I89eb519b22d21011d61a7855b2364bc3c295df82</p> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=294612024-03-02T16:36:55Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-2 priority-2 priority-default" href="/issues/6387">Feature #6387</a>: osmo_io / io_uring support for RTP/RTCP</i> added</li></ul> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=294642024-03-02T16:55:07Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-1 priority-2 priority-default" href="/issues/6388">Feature #6388</a>: stats_reporter via osmo_io / io_uring?</i> added</li></ul> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=294662024-03-02T16:56:02Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-1 priority-1 priority-lowest" href="/issues/6389">Feature #6389</a>: port VTY over to osmo_io / io_uring</i> added</li></ul> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=294682024-03-02T16:57:12Zlaforge
<ul><li><b>Checklist item</b> deleted (<strike><i>port vty over to osmo_io</i></strike>)</li><li><strong>Priority</strong> changed from <i>Immediate</i> to <i>High</i></li></ul>I've moved
<ul>
<li>the stats_reporter topic to a separate issue: <a class="issue tracker-2 status-1 priority-2 priority-default" title="Feature: stats_reporter via osmo_io / io_uring? (New)" href="https://osmocom.org/issues/6388">#6388</a></li>
<li>the vty topic to a separate issue: <a class="issue tracker-2 status-1 priority-1 priority-lowest" title="Feature: port VTY over to osmo_io / io_uring (New)" href="https://osmocom.org/issues/6389">#6389</a></li>
</ul>
<p>So let's only deal with CTRL within this topic. It's not critical but should hopefully be very quick.</p> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=294692024-03-02T18:45:15Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-1 priority-1 priority-lowest" href="/issues/6390">Feature #6390</a>: port CTRL over to osmo_io / io_uring</i> added</li></ul> libosmocore - Feature #5751: io_uring support in libosmocorehttps://osmocom.org/issues/5751?journal_id=294712024-03-02T18:46:08Zlaforge
<ul><li><b>Checklist item</b> deleted (<strike><i>port ctrl over to osmo_io</i></strike>)</li><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>70</i> to <i>100</i></li></ul><p>laforge wrote in <a href="#note-34">#note-34</a>:</p>
<blockquote>
<p>So let's only deal with CTRL within this topic. It's not critical but should hopefully be very quick.</p>
</blockquote>
<p>Sadly it is not trivial. Forked off to separate (low-prio) issue <a class="issue tracker-2 status-1 priority-1 priority-lowest" title="Feature: port CTRL over to osmo_io / io_uring (New)" href="https://osmocom.org/issues/6390">#6390</a></p>