On 6/14/19 7:52 AM, Tejun Heo wrote:

Hello, Quentin.

On Fri, Jun 14, 2019 at 12:32:09PM +0100, Quentin Monnet wrote:

quoted

Please make sure to update the documentation and bash
completion when adding the new type to bpftool. You
probably want something like the diff below.

Thank you so much.  Will incorporate them.  Just in case, while it's
noted in the head message, I lost the RFC marker while prepping this
patch.  It isn't yet clear whether we'd really need custom cost
functions and this patch is included more as a proof of concept.  

the example bpf prog looks flexible enough to allow some degree
of experiments. The question is what kind of new algorithms you envision
it will do? what other inputs it would need to make a decision?
I think it's ok to start with what it does now and extend further
when need arises.

If
it turns out that this is beneficial enough, the followings need to be
answered.

* Is block ioctl the right mechanism to attach these programs?

imo ioctl is a bit weird, but since its only one program per block
device it's probably ok? Unless you see it being cgroup scoped in
the future? Then cgroup-bpf style hooks will be more suitable
and allow a chain of programs.

* Are there more parameters that need to be exposed to the programs?

* It'd be great to have efficient access to per-blockdev and
   per-blockdev-cgroup-pair storages available to these programs so
   that they can keep track of history.  What'd be the best of way of
   doing that considering the fact that these programs will be called
   per each IO and the overhead can add up quickly?

Martin's socket local storage solved that issue for sockets.
Something very similar can work for per-blockdev-per-cgroup.