A new iteration of this patchset, previously known as write streams.
As before, this patchset aims at enabling applications split up
writes into separate streams, based on the perceived life time
of the data written. This is useful for a variety of reasons:
- With NVMe 1.3 compliant devices, the d
Jens,
> A new iteration of this patchset, previously known as write streams.
> As before, this patchset aims at enabling applications split up
> writes into separate streams, based on the perceived life time
> of the data written. This is useful for a variety of reasons:
>
> - With NVMe 1.3 compl
On 06/14/2017 09:45 AM, Martin K. Petersen wrote:
>
> Jens,
>
>> A new iteration of this patchset, previously known as write streams.
>> As before, this patchset aims at enabling applications split up
>> writes into separate streams, based on the perceived life time
>> of the data written. This i
Jens,
> So how about we just call it "write_hint"? It sounds mostly like a
> naming issue to me, as you would then map that to some specific stream
> in your driver. You're free to do that right now. They are all flags,
> it's just packed as a value to not waste too much space.
Sure, that's fine
On Wed, Jun 14, 2017 at 09:53:05AM -0600, Jens Axboe wrote:
> So how about we just call it "write_hint"? It sounds mostly like a
> naming issue to me, as you would then map that to some specific stream
> in your driver. You're free to do that right now. They are all flags,
> it's just packed as a v
On 06/14/2017 10:01 AM, Christoph Hellwig wrote:
> On Wed, Jun 14, 2017 at 09:53:05AM -0600, Jens Axboe wrote:
>> So how about we just call it "write_hint"? It sounds mostly like a
>> naming issue to me, as you would then map that to some specific stream
>> in your driver. You're free to do that ri
On 06/14/2017 10:00 AM, Martin K. Petersen wrote:
>
> Jens,
>
>> So how about we just call it "write_hint"? It sounds mostly like a
>> naming issue to me, as you would then map that to some specific stream
>> in your driver. You're free to do that right now. They are all flags,
>> it's just packe
Christoph,
> I think what Martin wants (or at least what I'd want him to want) is
> to define a few REQ_* bits that mirror the RWF bits, use that to
> transfer the information down the stack, and then only translate it
> to stream ids in the driver.
Yup. If we have enough space in the existing f
On 06/14/2017 10:04 AM, Martin K. Petersen wrote:
>
> Christoph,
>
>> I think what Martin wants (or at least what I'd want him to want) is
>> to define a few REQ_* bits that mirror the RWF bits, use that to
>> transfer the information down the stack, and then only translate it
>> to stream ids in
On 06/14/2017 10:04 AM, Martin K. Petersen wrote:
>
> Christoph,
>
>> I think what Martin wants (or at least what I'd want him to want) is
>> to define a few REQ_* bits that mirror the RWF bits, use that to
>> transfer the information down the stack, and then only translate it
>> to stream ids in
On Jun 14, 2017, at 10:04 AM, Martin K. Petersen
wrote:
> Christoph,
>
>> I think what Martin wants (or at least what I'd want him to want) is
>> to define a few REQ_* bits that mirror the RWF bits, use that to
>> transfer the information down the stack, and then only translate it
>> to stream i
On Wed, Jun 14, 2017 at 5:39 PM, Andreas Dilger wrote:
> On Jun 14, 2017, at 10:04 AM, Martin K. Petersen
> wrote:
>> Christoph,
>>
>>> I think what Martin wants (or at least what I'd want him to want) is
>>> to define a few REQ_* bits that mirror the RWF bits, use that to
>>> transfer the infor
On 06/14/2017 09:53 PM, Andreas Dilger wrote:
> On Jun 14, 2017, at 9:26 PM, Jens Axboe wrote:
>> On Wed, Jun 14, 2017 at 5:39 PM, Andreas Dilger wrote:
>>> On Jun 14, 2017, at 10:04 AM, Martin K. Petersen
>>> wrote:
Christoph,
> I think what Martin wants (or at least what I'd wan
On Jun 14, 2017, at 9:26 PM, Jens Axboe wrote:
> On Wed, Jun 14, 2017 at 5:39 PM, Andreas Dilger wrote:
>> On Jun 14, 2017, at 10:04 AM, Martin K. Petersen
>> wrote:
>>> Christoph,
>>>
I think what Martin wants (or at least what I'd want him to want) is
to define a few REQ_* bits tha
On 06/14/2017 09:57 PM, Jens Axboe wrote:
> On 06/14/2017 09:53 PM, Andreas Dilger wrote:
>> On Jun 14, 2017, at 9:26 PM, Jens Axboe wrote:
>>> On Wed, Jun 14, 2017 at 5:39 PM, Andreas Dilger wrote:
On Jun 14, 2017, at 10:04 AM, Martin K. Petersen
wrote:
> Christoph,
>
>>
> >From my perspective, all I really care about is the 4 hints. It's a
> simple enough interface that applications can understand and use it, and
> we don't need any management of actual stream IDs. I think that has the
> highest chance of success. Modifying an application to use it is
> trivial, e
On 06/16/2017 07:58 AM, Christoph Hellwig wrote:
>> >From my perspective, all I really care about is the 4 hints. It's a
>> simple enough interface that applications can understand and use it, and
>> we don't need any management of actual stream IDs. I think that has the
>> highest chance of succes
On Fri, Jun 16, 2017 at 08:40:11AM -0600, Jens Axboe wrote:
> On 06/16/2017 07:58 AM, Christoph Hellwig wrote:
> >> >From my perspective, all I really care about is the 4 hints. It's a
> >> simple enough interface that applications can understand and use it, and
> >> we don't need any management of
On 06/16/2017 09:52 AM, Christoph Hellwig wrote:
> On Fri, Jun 16, 2017 at 08:40:11AM -0600, Jens Axboe wrote:
>> On 06/16/2017 07:58 AM, Christoph Hellwig wrote:
>From my perspective, all I really care about is the 4 hints. It's a
simple enough interface that applications can understand
19 matches
Mail list logo
