On Tue, 2022-03-01 at 09:40 -0800, Luis Chamberlain wrote: > On Tue, Mar 01, 2022 at 12:14:49PM -0500, James Bottomley wrote: > > It looks fairly similar given the iouring syscalls are on an fd > > except > > that the structure above hash to be defined and becomes an > > ABI. Since > > they configfd uses typed key value pairs, i'd argue it's more > > generic > > and introspectable. > > I'm not suggesting using io-uring cmd as a configuration alternative > to configfd, I'm suggesting it can be an async *vehicle* for a bunch > of configurations one might need to make in the kernel. If we want > to reduce system call uses, we may want to allow something like > configfd to accept a batch of configuration options as well, as a > batcha, and a final commit to process them. Well, that's effectively how it does operate. Configfd like configfs is a dedicated fd you open exclusively for the purpose of configuration. You send it the key/value pairs via the action system call. Although the patch sent used "basic" types as values, nothing prevents them being composite types that are aggregated, which would be an easy mechanism for batching. However, I'd like to add a note of caution: just because we *can* do batching with the interface doesn't mean we should. One of the benefits of using simple basic types is easy interpretation by things like seccomp; the more complex you make the type, the more internal knowledge the seccomp/ebpf script needs. So can I ask just how important batching for configuration changes is? I get that there's some overhead for doing effectively one syscall per k/v pair, but configuration operations aren't usually that time critical. If you're sending passthrough, then I can see you don't want a load of syscalls per op, but equally a passthrough is just an opaque packet that's likely not introspectable anyway, so it's a single k/v pair. James
