No way to do getsockname() for a direct socket

[ned14]

I have an io_uring based application where I am debugging socket connections between server and client. Printing the port which the client is using to connect is a reasonable way to map between server and client.

Unfortunately, io_uring provides no equivalent to getsockname() as far as I can tell for sockets connected using io_uring_prep_connect() with IOSQE_FIXED_FILE where there is no userspace file descriptor available.

I appreciate that this is a very minor corner case, but I make the suggestion for this feature addition anyway.

[axboe]

If it's just for debug purposes, you can always transform the direct descriptor into a regular one with io_uring_prep_fixed_fd_install().

[ned14]

Good idea, alas I am on kernel 6.8, so no go on that idea. It's okay, I'll make an associative map in shared memory, that's portable.

I guess it just struck me as missing functionality and I could find no mention of it anywhere on here. Technically I suppose getpeername() is also needed, as what the system actually connects to isn't necessarily exactly what you ask io_uring to connect to, and sometimes that is very important to know more about.

[axboe]

Yep that won't work in 6.8. For what it's worth, 6.8 isn't a good base to begin with, as it's not receiving stable fixes for the kernel in general...

We could wire up getsockname/getpeername, and may do so at some point. It'd be very trivial to do.

[ned14]

Kernel 6.8 is the Ubuntu 24.04 LTS kernel, and no I am not allowed to deviate from the stock image.

At some point a 24.04 LTS update will push kernel 6.14 (Autumn 2025?), but until then, I am stuck with what I have before me.

[axboe]

It is what it is, if you're stuck with that. It's more of a distro than user problem obviously, and at least distros are moving more towards current (or at least stable) kernels rather than clinging on to their own bastardized versions.

[ned14]

You're absolutely right on that. Even just a few years ago I had to keep code working on Linux 2.6 due to RHEL6. We had a huge number of hack workarounds for the bugs in that kernel. The kernel 3.x still had workarounds, it took until kernel 4.x before, generally speaking, no more workarounds needed and what works without issue on other OSs also worked without issues on Linux.

Kernel 6.8 in comparison is extremely new and trouble free, and I'm very glad for that. Same code goes noticeably quicker on newer kernels too.

Kernel 6.14 doesn't have anything I'm desperate to get, just a few nice to haves. Even with io_uring, for the hardware we currently use, we're pretty much maxing it out already. Further perf gains in io_uring won't benefit us by much until the hardware spec greatly improves. I'm looking to buy one of those upcoming Samsung 9900 SSDs, see how things work at PCIe 5.0 goodness. I expect our current system to max that out too, our i/o benchmark tool using our async i/o framework returns ~18% better performance than your fio tool and yes, it is correctly measuring the same thing. We wrote ours recently knowing everything we know now, so we could wrap it especially tightly around modern io_uring and then we tuned it heavily. I'm very sure if you rewrote fio from scratch knowing what you know now and only supporting modern io_uring, you'd get similar perf gains.

[stonebrakert6]

I have a similar use-case and need the ip address of remote peer.
I am using io_uring_prep_multishot_accept_direct(sqe, fd_, peer_addr_, addr_len_, flags_);
So I believe I can't use peer_addr and addr_len to get the remote peer as multiple completions would over-write the same memory.

So I wanted to use something equivalent of getpeername on the connected fd(direct descriptor) to get the remote client ip address(and port)

We could wire up getsockname/getpeername, and may do so at some point. It'd be very trivial to do.

@axboe did you mean using io_uring_prep_fixed_fd_install() you would build getpeername or what?

Should I go ahead and useio_uring_prep_fixed_fd_install() to implement this functionality for my application for the time being till we get io_uring equivalent of getpeername/getsockname?

[isilence]

I'll take a look at wiring a new command