Feature #6357
closed
run (some?) tests with io_uring backend for osmo_io
Added by laforge 3 months ago.
Updated about 2 months ago.
Description
For quite some time, we have the new osmo_io abstraction layer with two backends:
- the [default] poll backend
- the new io_uring backend
This means we should start (or have started) testing not just with the default backend, but also with the io_uring based backend. Running the TTCN-3 test suites in both modes should give us an opportunity to see if there's any differences in tests passing/failing between the backends.
As we're soon moving more relevant sub-systems over to osmo_io (libosmo-sigtran being an important step) this becomes more and more relevant.
The question is which tests we should run twice. I think we should start at least with
- osmo-bts
- osmo-bsc
- osmo-mgw
- osmo-msc
- osmo-stp
- osmo-hnbgw
All of the above are used in performance-critical production deployments where users are waiting for io_uring based improvements.
STP/BSC/MSC are important given the imminent libosmo-sigtran/SCTP support for osmo_io
- Related to Feature #5752: io_uring support in libosmo-sigtran added
- Related to Bug #5756: io_uring support in libosmo-abis added
- Related to Feature #5753: io_uring support in libosmo-netif added
- Related to Feature #5754: io_uring support in libosmo-mgcp-client added
osmo-gbproxy is what I used for manual testing since ns2 already uses osmo_io. That will not test connected sockets, though, only UDP.
In case it was unclear you can set LIBOSMO_IO_BACKEND=IO_URING when running a program an it will use the io-uring backend.
On Fri, Feb 09, 2024 at 04:09:19PM +0000, daniel wrote:
osmo-gbproxy is what I used for manual testing since ns2 already uses osmo_io. That will not test connected sockets, though, only UDP.
yeah, I think we want something automatic/continuous, and covering at least one subsystem
using each:
- UDP
- TCP client
- TCP server
- SCTP client
- SCTP server
this is becoming a more pressing need now. We are migrating more and more sub-systems over to osmo_io and still have no tests executed with the non-default (io_uring) backend.
If osmith has no time to look into it, maybe you have at least some input and can help jolly to make this happen?
Right now we have the following osmo_io using code in place (together with some users):
| library/interface |
protocol |
transport |
users |
| libosmo-mgcp-client |
MGCP |
UDP |
osmo-bsc, osmo-msc, osmo-hnbgw |
| libosmogb ns2 |
NS |
UDP |
osmo-pcu, osmo-gbproxy, osmo-sgsn |
| osmo-bsc |
CBSP |
TCP client+server |
osmo-bsc |
| osmo-bsc |
meas_feed |
UDP |
osmo-bsc |
(I've addded this table to a new wiki page osmo_io)
We are just about to merge support in libosmo-sigtran (TCP/SCTP) used by osmo-{bsc,msc,stp,hnbgw,sgsn}
- % Done changed from 0 to 90
Sorry that it took me a bit to get to this, the patch to make this happen is actually quite small. I've discussed with Jolly, and we decided it would be fastest if I implement it and he reviews it.
- Status changed from New to Resolved
- % Done changed from 90 to 100
On Thu, Mar 14, 2024 at 05:07:28PM +0000, osmith wrote:
patch https://gerrit.osmocom.org/c/osmo-ci/+/36272 limits the nodes the testsuites can run on, as we have seen that io_uring_queue_init fails on host2-deb11build-ansible. I suspect the host kernel is too old.
Not from my knowledge. The Debian 11 kernel very well supports io_uring.
Debian11 also ships a liburing package, and when Daniel and I started
the osmo_io development, Debian12 didn't even exist.
So there is something more going on here, and I do think it is worth understanding it. As I hinted,
maybe a problem when using the debian12 liburing on a debian11 kernel?
laforge wrote in #note-13:
So there is something more going on here, and I do think it is worth understanding it. As I hinted,
maybe a problem when using the debian12 liburing on a debian11 kernel?
Following up in #6405.
Also available in: Atom
PDF
