On Mon, Aug 26, 2019 at 01:20:28PM +0200, Marta Rybczynska wrote:
> Do you mean something like this?
Yes.
- On 22 Aug, 2019, at 02:06, Christoph Hellwig h...@lst.de wrote:
> On Fri, Aug 16, 2019 at 11:47:21AM +0200, Marta Rybczynska wrote:
>> It is not possible to get 64-bit results from the passthru commands,
>> what prevents from getting for the Capabilities (CAP) property value.
>>
>> As a
On Fri, Aug 16, 2019 at 11:47:21AM +0200, Marta Rybczynska wrote:
> It is not possible to get 64-bit results from the passthru commands,
> what prevents from getting for the Capabilities (CAP) property value.
>
> As a result, it is not possible to implement IOL's NVMe Conformance
> test 4.3 Case 1
On Mon, Aug 19, 2019 at 08:49:22AM -0600, Keith Busch wrote:
> On Mon, Aug 19, 2019 at 12:06:23AM -0700, Marta Rybczynska wrote:
> > - On 16 Aug, 2019, at 15:16, Christoph Hellwig h...@lst.de wrote:
> > > Sorry for not replying to the earlier version, and thanks for doing
> > > this work.
> > >
On Mon, Aug 19, 2019 at 02:17:44PM -0700, Sagi Grimberg wrote:
>
> - On 16 Aug, 2019, at 15:16, Christoph Hellwig h...@lst.de wrote:
> > Sorry for not replying to the earlier version, and thanks for doing
> > this work.
> >
> > I wonder if instead of using our own structur
- On 16 Aug, 2019, at 15:16, Christoph Hellwig h...@lst.de wrote:
Sorry for not replying to the earlier version, and thanks for doing
this work.
I wonder if instead of using our own structure we'd just use
a full nvme SQE for the input and CQE for that output. Even if we
reserve a few fi
On Mon, Aug 19, 2019 at 11:56:28AM -0700, Sagi Grimberg wrote:
>
> >> - On 16 Aug, 2019, at 15:16, Christoph Hellwig h...@lst.de wrote:
> >>> Sorry for not replying to the earlier version, and thanks for doing
> >>> this work.
> >>>
> >>> I wonder if instead of using our own structure we'd jus
- On 16 Aug, 2019, at 15:16, Christoph Hellwig h...@lst.de wrote:
Sorry for not replying to the earlier version, and thanks for doing
this work.
I wonder if instead of using our own structure we'd just use
a full nvme SQE for the input and CQE for that output. Even if we
reserve a few fi
On 8/19/2019 7:49 AM, Keith Busch wrote:
On Mon, Aug 19, 2019 at 12:06:23AM -0700, Marta Rybczynska wrote:
- On 16 Aug, 2019, at 15:16, Christoph Hellwig h...@lst.de wrote:
Sorry for not replying to the earlier version, and thanks for doing
this work.
I wonder if instead of using our ow
On Mon, Aug 19, 2019 at 12:06:23AM -0700, Marta Rybczynska wrote:
> - On 16 Aug, 2019, at 15:16, Christoph Hellwig h...@lst.de wrote:
> > Sorry for not replying to the earlier version, and thanks for doing
> > this work.
> >
> > I wonder if instead of using our own structure we'd just use
> >
- On 16 Aug, 2019, at 15:16, Christoph Hellwig h...@lst.de wrote:
> Sorry for not replying to the earlier version, and thanks for doing
> this work.
>
> I wonder if instead of using our own structure we'd just use
> a full nvme SQE for the input and CQE for that output. Even if we
> reser
Sorry for not replying to the earlier version, and thanks for doing
this work.
I wonder if instead of using our own structure we'd just use
a full nvme SQE for the input and CQE for that output. Even if we
reserve a few fields that means we are ready for any newly used
field (at least until the S
It is not possible to get 64-bit results from the passthru commands,
what prevents from getting for the Capabilities (CAP) property value.
As a result, it is not possible to implement IOL's NVMe Conformance
test 4.3 Case 1 for Fabrics targets [1] (page 123).
This issue has been already discussed
13 matches
Mail list logo