Feature #6357
closedrun (some?) tests with io_uring backend for osmo_io
100%
Description
- 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 issues
Updated by laforge 3 months ago
- Related to Feature #5752: io_uring support in libosmo-sigtran added
Updated by laforge 3 months ago
- Related to Feature #5753: io_uring support in libosmo-netif added
Updated by laforge 3 months ago
- Related to Feature #5754: io_uring support in libosmo-mgcp-client added
Updated by laforge 3 months ago
- Related to Feature #5751: io_uring support in libosmocore added
Updated by laforge 3 months ago
- Related to Feature #5755: io_uring support in osmo-bsc added
Updated by laforge 3 months ago
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
Updated by laforge about 1 month ago
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}
Updated by osmith about 1 month ago
- % 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.
Updated by osmith about 1 month ago
- Status changed from New to Resolved
- % Done changed from 90 to 100
Updated by osmith about 1 month ago
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.
Updated by laforge about 1 month ago
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?
Updated by osmith about 1 month ago
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.
