On Tue, Mar 01, 2022 at 01:08:34PM -0500, James Bottomley wrote: > 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. This alone makes a good argument against ioctls. > So can I ask just how important batching for configuration changes is? A great question. I can't personally think of use cases unless you want batch configuration with IO operations. io-uring stuff does have some link where in this regard, given some IO ops also may expose new fds for instance, which you may later want to use for further IO processing... but that seems very different than just the question of batching for configuration. > 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. Agreed and I'd like to hear arguments which would suggest otherwise. > 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. I think it might be fair to detach config / IO calls. Joshi however might have more to say about if we really would need to mesh the two. Luis
