On 1/17/20 2:32 AM, Pavel Begunkov wrote: > On 1/17/2020 3:44 AM, Colin Walters wrote: >> On Thu, Jan 16, 2020, at 5:50 PM, Stefan Metzmacher wrote: >>> The client can compound a chain with open, getinfo, read, close >>> getinfo, read and close get an file handle of -1 and implicitly >>> get the fd generated/used in the previous request. >> >> Sounds similar to https://capnproto.org/rpc.html too. >> > Looks like just grouping a pack of operations for RPC. > With io_uring we could implement more interesting stuff. I've been > thinking about eBPF in io_uring for a while as well, and apparently it > could be _really_ powerful, and would allow almost zero-context-switches > for some usecases. > > 1. full flow control with eBPF > - dropping requests (links) > - emitting reqs/links (e.g. after completions of another req) > - chaining/redirecting > of course, all of that with fast intermediate computations in between > > 2. do long eBPF programs by introducing a new opcode (punted to async). > (though, there would be problems with that) > > Could even allow to dynamically register new opcodes within the kernel > and extend it to eBPF, if there will be demand for such things. We're also looking into exactly that at Facebook, nothing concrete yet though. But it's clear we need it to take full advantage of links at least, and it's also clear that it would unlock a lot of really cool functionality once we do. Pavel, I'd strongly urge you to submit a talk to LSF/MM/BPF about this. It's the perfect venue to have some concrete planning around this topic and get things rolling. https://lore.kernel.org/bpf/20191122172502.vffyfxlqejthjib6@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ -- Jens Axboe
