pawelgaczynski / giouring Goto Github PK

Some helper methods accept buffers as parameters of type []byte (e.g. PrepareSendZC) and others as type of uintptr (e.g. PrepareRecv).
It is necessary to choose one right way and make the API consistent.

Submission/completion queue events has methods SetData/GetData to pack unsafe.Pointer into uint64 and restore it back. I'm far from the expert, but according to my current understanding that can't be used in Go. That case in not covered by unsafe.Pointer allowed operations.

Here is trivial example of taking pointer to the function, converting it to uintptr then back to pointer and calling that function.
It will work when executed with go run. Will show warning 'possible misuse of unsafe.Pointer' in playground and will fail with 'fatal error: checkptr: pointer arithmetic result points to invalid allocation' when run with runtime verification go run -gcflags=all=-d=checkptr

package main

import (
	"fmt"
	"unsafe"
)

func main() {
	cb := func() {
		fmt.Println("called")
	}

	ptr := uintptr(unsafe.Pointer(&cb))
	(*(*func())(unsafe.Pointer(ptr)))()
}

It seams that there is no way to use this two methods (or any other way of using pointers) to pass useful data between submission and completion.

Setting submission UserData to some map key or array index of the callbacks seams to be the way to connect completion with something to call with results.

According to the liburing documentation for any request that passes in data in a struct, that data must remain valid until the request has been successfully submitted:

For any request that passes in data in a struct, that data must remain valid until the request has been successfully submitted. It need not remain valid until completion. Once a request has been submitted, the in-kernel state is stable. Very early kernels (5.4 and earlier) required state to be stable until the completion occurred. Applications can test for this behavior by inspecting the IORING_FEAT_SUBMIT_STABLE flag passed back from io_uring_queue_init_params(3). In general, the man pages for the individual prep helpers will have a note mentioning this fact as well, if required for the given command.

It would be useful to add this info to the documentation of helper methods, and to add a link to examples of how you can ensure the validity of this data in Go language (e.g. keeping pointer to data until the successful submission or using runtime.KeepAlive method).

It may also be worth designing and implementing a higher abstraction layer that automatically ensures data validity.

Similar to #13

Params has all fields private. But it make sense to be able to modify at least few (possibly more, if one does everything manually).

sqThreadIdle and sqThreadCPU would be ones that would be most useful and simple to expose.

features does not need to be exposed, as this is filled by kernel, and giouring copies it to ring.features on success. But ring.features is not accessible, and only used internally. There are situations, where one would want to know the features, for example to check if IORING_FEAT_SUBMIT_STABLE is set, and possibly more (IORING_FEAT_NATIVE_WORKERS, IORING_FEAT_CQE_SKIP, IORING_FEAT_SQPOLL_NONFIXED, IORING_FEAT_RW_CUR_POS are of highest interest to me).

So, currently with current Params, it not really possible to do much with few functions like Setup, QueueInitParams, and if somebody is advantageous QueueInitMem

I added this project to pkg.go.dev:
https://pkg.go.dev/github.com/pawelgaczynski/giouring

Here's the link for the readme:

Cheers and thanks for providing this!

type Ring has fd fields that are not available externally (lower case), but the file descripter in particular is required as parameter in the method (*ring).Register (https://github.com/pawelgaczynski/giouring/blob/69588b89acb9/syscall.go#L94).

Currently, the alternative is not to use the library method QueueInit and instead implement Setup (https://github.com/pawelgaczynski/giouring/blob/69588b89acb9/syscall.go#L72) which return the file descriptor.

ps. I discovered that you added a method in setup.go (*ring)RingFd().
Would it not be cleaner to define the fields externally?

Hello

I have some working examples using giouring for UDP read/write and for TCP accept/read/write. I am struggling to build a TCP connect/read/write example because when I submit a Connect request (using PrepareConnect and Submit) I get an error in the cqe.Res of -97 which is "Address family not supported by protocol".

My socket is established as:
fd, err := unix.Socket(unix.AF_INET, unix.SOCK_STREAM, unix.IPPROTO_TCP)
and I've used both syscall.SockaddrInet4 and unix.SockaddrInet4, both times casting the pointer to unsafe and then to (*syscall.Sockaddr), or alternatively creating a var with syscall.Sockaddr(serverAddr) and using a pointer to that. I just can't make it accept this address. I even tried building a golang equivalent of struct sockaddr_in in case it was expecting something like that.

Please could you provide a trivial example of a TCP connect over io_uring? It would really help.

Thanks

Implement typical examples of library use:

• file operations (writing, reading),
• network operations (receiving and sending data),
• registration of files and buffers.