hi, I spent some time to write v2, especially think about how to work around task_work_add is not exported, so sorry for late response. > >>> The above is for setting up target io parameter, which is supposed >>> to be from userspace, cause it is result of user space logic. If >>> these parameters are from kernel, the whole logic has to be done >>> in io_prep_prog. >> Yeah, it's designed that io_prep_prog implements user space >> io logic. > That could be the biggest weakness of this approach, because people > really want to implement complicated logic in userspace, which should > be the biggest value of ublk, but now seems you move kernel C > programming into ebpf userspace programming, I don't think ebpf > is good at handling complicated userspace logic. Absolutely agree with you, ebpf has strict programming rules, I spent more time than I had thought at startup for support loop target ebpf prog(ublk.bpf.c). Later I'll try to collaborate with my colleagues, to see whether we can program their userspace logic into ebpf prog or partially. >> io_prep_prog is called when ublk_queue_rq() is called, this bpf >> prog will initialize one or more sqes according to user logic, and >> io_prep_prog will put these sqes in an ebpf map structure, then >> execute a task_work_add() to notify ubq_daemon to execute >> io_submit_prog. Note, we can not call io_uring_submit_sqe() >> in task context that calls ublk_queue_rq(), that context does not >> have io_uring instance owned by ubq_daemon. >> Later ubq_daemon will call io_submit_prog to submit sqes. > Submitting sqe from kernel looks interesting, but I guess > performance may be hurt, given plugging(batching) can't be applied > any more, which is supposed to affect io perf a lot. Yes, agree, but I didn't have much time to improve this yet. Currently, I mainly try to use this feature on large ios, to reduce memory copy overhead, which consumes much cpu resource, our clients really hope we can reduce it. Regards, Xiaoguang Wang > > > > Thanks, > Ming
