Osmocom Libraries » libosmocore

I'd like the idea of splitting tihs into two separate sub-tasks:

1. introduce the conceptual API changes of having the actual read/write done inside libosmocore; then start to port applications over to that new API
2. subsequently (and fully optionally) introduce an io_uring backend to libosmocore so it can benefit from the related performance improvements.

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.

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.

for some existing example how to use io_uring in the osmocom context, check out rtp-load-gen at https://gitea.osmocom.org/cellular-infrastructure/osmo-mgw/src/branch/laforge/rtp-load-gen/contrib/rtp-load-gen and grep for io_uring_ showing the various API calls. There's also https://gitea.osmocom.org/cellular-infrastructure/gtp-load-gen

• io_uring_get_sqe returns an unused submission queue entry
• io_uring_prep_write and io_uring_prep_write fills that submission queue entry with a fd, pointer to data + length
• io_uring_submit submits whatever prepared submission queue entries

• io_uring tutorial at https://unixism.net/loti/tutorial/index.html
• liburing code at https://github.com/axboe/liburing

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.

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: https://blog.cloudflare.com/missing-manuals-io_uring-worker-pool/ is worth a read) that just end up somewhere, without easy ways to move those to a specific cpu.

On Wed, Nov 09, 2022 at 01:58:54PM +0000, Hoernchen wrote:

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: https://blog.cloudflare.com/missing-manuals-io_uring-worker-pool/ is worth a read) that just end up somewhere, without easy ways to move those to a specific cpu.

AFAICT there are no kernel threads created for socket read/write, as sockets support non-blocking operation.

99.9% of all I/O we are doing is on sockets (UDP, TCP, SCTP, Unix) for talking to other network elements or
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.

summary of some of my ideas / thoughts on the new I/O provider so far:

• modes. The new I/O provider will need to offer the following modes:
  • read/write (e.g. tcp sockets for IPA OML/RSL/GSUP as well as CBSP, VTY, CTRL, ...)
  • recvfrom/sendto (e.g. UDP sockets used for RTP, GTP, MGCP, ...)
    • 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
    • we have to convert recfrom/sendto by API users (applications) to recvmsg/sendmsg
  • sctp_recvfrom/sctp_sendto (SCTP sockets for anything M3UA/SUA/sigtran)
    • this API from libsctp is just a 20-line wrapper around normal recvmsg/sendmsg calls
    • we have to re-implement this wrapper in our io_uring code
• introduction of a new struct osmo_io_fd which will be used instead of osmo_fd, containing
  • fd
  • const char *name for application to provide a human-readable name of the FD (in case I/O provider wants to log something)
  • parameters for msgb_alloc (headroom, context, size)
  • a built-in write-queue with semantics like osmo_wqueue
  • call-back functions for the user application (read/write completion call-backs)
  • priv/priv_nr for context of application (like osmo_fd)
• write operation
  • application does something like osmo_io_write(struct osmo_io_fd *, struct msgb *)
  • I/O provider enqueues any write into write queue and marks FD as "wants to write"
  • io_uring backend
    • would check if write is pending completion. If not, submit first entry of write_queue to io_uring
    • at some later point, I/O provider io_uring backend is notified via osmo_fd-wapped-eventfd that io_uring has completed something
    • once I/O provider io_uring backend identifies a write has completed, it will call the io_fd->write_cb(struct osmo_io_fd *fd, int rc, struct msgb *msg) call-back
  • classic poll backend
    • would now check if OSMO_FD_WRITE is active. If not, set it.
    • gets notified that osmo_fd is writable
    • issues normal non-blocking write() syscall
    • call the io_fd->write_cb(struct osmo_io_fd *fd, int rc, struct msgb *msg) call-back
  • the application can now act basd on rc (short write, negative error, dead socket, etc)
  • once call-back returns, I/O provider does msgb_free(msg)
• read operation
  • application notifies I/O provider that it wants to read from osmo_io_fd
  • io_uring backend
    • allocates a msgb (using parameters provided by application stored in osmo_io_fd
    • submits a read() syscall to io_uring submission queue pointing to msgb memory
    • completion is handled just like the write completion via osmo_fd-wrapped-eventfd
    • io_fd->read_cb(struct osmo_io_fd *fd, int rc, struct msgb *msg) is called
  • classic poll backend
    • enables OSMO_FD_READ on socket
    • gets notified that osmo_fd is readable once data is available
    • allocates a msgb (using parameters provided by application stored in osmo_io_fd
    • issues normal non-blocking read() syscall
    • io_fd->read_cb(struct osmo_io_fd *fd, int rc, struct msgb *msg) is called

For the {send,recv}{to,from,msg}() family of calls, we need to extend the above slightly. In addition the raw msgb, we have metadata like the struct sockaddr to send to.

I originally thought we could push this to the front of the msgb headroom, but sockaddr_storage is already 128 bytes plus the struct msghdr struct iovec 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.

I then decided to go for a struct serialized_msghdr which we allocate at the time the user issues e.g. a osmo_io_sendto(struct osmo_io_fd *, struct msgb *msg, int flags, const struct sockaddr *dest_addr, socklen_t addrlen) call. The function would then copy the provided parameters into that heap-allocated serialized_msghdr, and enqueue that (instead of the pure msg) into the in-memory transmit queue. Once the actual sendmsg 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 serialized_msghdr as well as the msgb afterwards.

The same approach also works for the recvmsg/recvffrom case, where we can have an application call-back like void (*recvfrom_cb)(struct osmo_io_fd *iofd, int rc, struct msgb *msg, struct sockaddr *src_addr, socklen_t *addrlen);

Equally this approach works for sctp_sendmsg/sctp_recvmsg as those are just wrappers with different function arguments that all get encoded into a struct msghdr.

In order to push this forward a bit while daniel 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".

stats_reporter¶

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 sendto(). 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.

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.

ctrl¶

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.

vty¶

The VTY uses its 'buffer' layer between writes by the software and writing to the acutal socket file descriptor. buffer_flush_all is currently used whenever the socket is write-able. So it's a pull model.

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.

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.

SCTP support (indirectly, by sendmsg/recvmsg support) for osmo_io is in libosmocore since Change-Id I89eb519b22d21011d61a7855b2364bc3c295df82