On 9/18/2024 12:12 PM, Christoph Hellwig wrote:
>>> If the device (or file system, which really needs to be in control
>>> for actual files vs just block devices) does not support all 256
>>> we need to reduce them to less than that. The kernel can help with
>>> that a bit if the streams have meanings (collapsing temperature levels
>>> that are close), but not at all if they don't have meanings.
>> Current patch (nvme) does what you mentioned above.
>> Pasting the fragment that maps potentially large placement-hints to the
>> last valid placement-id.
>>
>> +static inline void nvme_assign_placement_id(struct nvme_ns *ns,
>> + struct request *req,
>> + struct nvme_command *cmd)
>> +{
>> + u8 h = umin(ns->head->nr_plids - 1,
>> + WRITE_PLACEMENT_HINT(req->write_hint));
>> +
>> + cmd->rw.control |= cpu_to_le16(NVME_RW_DTYPE_DPLCMT);
>> + cmd->rw.dsmgmt |= cpu_to_le32(ns->head->plids[h] << 16);
>> +}
>>
>> But this was just an implementation choice (and not a failure avoidance
>> fallback).
> And it completely fucks thing up as I said. If I have an application
> that wants to separate streams I need to know how many stream I
> have available, and not fold all higher numbers into the last one
> available.
Would you prefer a new queue attribute (say nr_streams) that tells that?
