On 06/16/2017 01:33 AM, Christoph Hellwig wrote: > On Thu, Jun 15, 2017 at 08:21:18AM -0600, Jens Axboe wrote: >> I'd still very much like to stick to the same four hints, and not > > Agreed. In fact I'd go a little further: we should have a > > u16 hints; > > that goes all the way down from fcntl to the driver, right now > we'll allocate the first 3 bits for the write lifetime hints (2.5, > so we have one value spare, as they don't need to flags but can be > enum values), leaving more space for other kinds of hints. Did you see v5? It adds enum write_hint and passes it all the way down, until we transform them into rq/bio flags. >> require any special setup. I think the lazy setup for nvme is fine. Some >> devices can do it at probe time, others will want to do it lazily to not >> waste resources. Do we really want to have the HINT_SET bubble down to >> the device and allocate streams? > > If I look at the mess for allocating the streams I think we need it > to bubble down. That way the device can allocate the stream at time > of the fcntl and we can keep the low level driver very simple. Mess? The NVMe code seems pretty straight forward to me. Is it purely the lazy alloc part you're referring to? I'm fine with bubbling down the hint and setting everything up inline from the fcntl() call, but that means we need to make things like btrfs and md/dm aware of it and resolve all mappings. That sort-of sucks, especially since they don't otherwise need to know about it. If another driver needs similar setup like NVMe, I'd much rather just fix it up there. From the API point of view, there would be no changes. -- Jens Axboe
