On 06/16/2017 12:02 PM, Christoph Hellwig wrote: > On Fri, Jun 16, 2017 at 09:59:38AM -0600, Jens Axboe wrote: >>>> Did you see v5? It adds enum write_hint and passes it all the way down, >>>> until we transform them into rq/bio flags. >>> >>> Yes. But with all the way down I mean all the way down to the driver :) >> >> Only missing part is the request flags. And why make that any different >> than the flags we already have now? It'd be trivial to pack the value >> into the request flags as well, but I'm struggling to see the point of >> that, honestly. >> >> Please expand on why you think changing the request flags to also >> carry that value would be useful, as opposed to just mapping it when >> we setup the request. If you have a valid concern I don't mind making >> the change, but I just don't see one right now. > > Mostly so that we can pass the value down in one form through the whole > stack. OK good, so we have that now. I guess the one change we could further make is have the write hints be a subset of the possible hints. I already made changes to reflect that in the latest posting, where we have a rw_hint enum. I haven't made any division of it into read vs write hints, but that could always be done and it won't impact the API since we can just keep the write hints in the lower 8-16 bits, or whatever we choose. >> How so? It's pretty straight forward. The only downside I see is that >> we'll have a delay between seeing the first valid write hint and to >> the time when nvme has it enabled. But that's so short, and in the >> grander scheme of things, doesn't matter one bit. > > I'll take your word for that. To be honest I hope future standards > won't make the mistake to come up with something as ugly as streams > and just take something like our hints on a per-I/O basis.. Well, at least streams is better than how it started out... -- Jens Axboe
