Hello, Tejun

在 2026/9/9 04:31, Tejun Heo 写道:
> Hello, Tao.
> 
> On Tue, 08 Sep 2026 18:01:35 +0800, Tao Cui wrote:
> 
>>  4. One model system-wide vs named models selectable per device (as
>>     tcp-cc names are per-socket)?
> 
> The struct_ops instance should be per-device. Loading a model for a device
> should switch it to BPF automatically. Switching back to the builtin model
> should detach the struct_ops.
> 
>>  2. Per-cgroup state lifetime: iocg_id is the css id and is recycled
>>     once the cgroup is removed, so models must treat it as a
>>     transient key.  Does the interface need a release(iocg_id)
>>     callback so models can clean up per-cgroup state instead of
>>     detecting reuse, or is per-cgroup bpf local storage, which
>>     carries its own lifetime, the better home for model state?
> 
> I'd pass blkcg as a kptr and add online/offline callbacks so the model can
> manage its per-cgroup state.
> 
>> return value of 0 delegates the IO back to the builtin formula, so a
>> model which only handles some IO types cannot make the rest free.
> 
> I don't think mixing BPF and builtin pricing makes sense, either per IO or
> between charging and request sizing. It seems convoluted and error-prone.
> Implementing the linear model in BPF is straightforward.
> 
> Please combine the interface, registration, dispatch and configuration
> changes into one patch. These patches are small and implement one feature.
> 

Thanks for the detailed review across the series.

All the comments make sense. I'm reworking the interface for v2
along those lines: the attachment model will be reworked, the
mixed builtin/BPF pricing path will go away so a model fully owns
pricing on a device it's attached to (including flushes), the
per-cgroup state handling is being reworked, operation flags will
be preserved, and sleepable models will be rejected during
verification.

The Kconfig dependency, the example model issues, the selftest
problems, and the patch organization will all be addressed as well.

I'll post v2 once it's ready.

Thanks,
Tao

> Thanks.
> 


Reply via email to