On 1/17/20 3:27 PM, Pavel Begunkov wrote: > On 17/01/2020 18:21, Jens Axboe wrote: >> 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. > > Sounds interesting, I'll try this, but didn't you intend to do it > yourself? And thanks for the tip! Just trying to delegate a bit, and I think you'd be a great candidate to drive this. I'll likely do some other io_uring related topic there. -- Jens Axboe
