Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: xer2PCHgzLrObSTorY1ECQMNYCgETlb9NXGAVQE6JR6UrxDrjb1PQhx6MEQ6p2060ayF1lE20I
 KS/ShyQsSAmAwDxzpqRtZRHIPdfUARSDXW1pxiq3PM0RxpIl7raFwTJhCoeD7x19vtO9Qd8hlh
 mUnqnCsGTYBAbDo8CMtgEjL4fexEA24rFSOG0SJAvtojU3++h8gameUe0aRgdpLiay50SN5xSG
 jAkb6Xmcr+ICdzqrlKXAcuCypttqaaIogNqVh4q/lDCOlUND+0HzNrCqxpMTRElqnhCkYobpP6
 y2U=
From:   Damien Le Moal <Damien.LeMoal@wdc.com>
To:     Kanchan Joshi <joshiiitr@gmail.com>,
        Matthew Wilcox <willy@infradead.org>
CC:     "hch@infradead.org" <hch@infradead.org>,
        Jens Axboe <axboe@kernel.dk>,
        Kanchan Joshi <joshi.k@samsung.com>,
        "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
        "bcrl@kvack.org" <bcrl@kvack.org>,
        "asml.silence@gmail.com" <asml.silence@gmail.com>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        Matias Bj??rling <mb@lightnvm.io>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-aio@kvack.org" <linux-aio@kvack.org>,
        "io-uring@vger.kernel.org" <io-uring@vger.kernel.org>,
        "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
        Selvakumar S <selvakuma.s1@samsung.com>,
        Nitesh Shetty <nj.shetty@samsung.com>,
        Javier Gonzalez <javier.gonz@samsung.com>
Subject: Re: [PATCH v3 4/4] io_uring: add support for zone-append
Thread-Topic: [PATCH v3 4/4] io_uring: add support for zone-append
Thread-Index: AQHWUv1xEGaGdzUuiUilHzifWt+jQw==
Date:   Tue, 21 Jul 2020 00:59:59 +0000
Message-ID: <CY4PR04MB37513C3424E81955EE7BFDA4E7780@CY4PR04MB3751.namprd04.prod.outlook.com>
References: <2270907f-670c-5182-f4ec-9756dc645376@kernel.dk>
 <CA+1E3r+H7WEyfTufNz3xBQQynOVV-uD3myYynkfp7iU+D=Svuw@mail.gmail.com>
 <f5e3e931-ef1b-2eb6-9a03-44dd5589c8d3@kernel.dk>
 <CA+1E3rLna6VVuwMSHVVEFmrgsTyJN=U4CcZtxSGWYr_UYV7AmQ@mail.gmail.com>
 <20200710131054.GB7491@infradead.org>
 <20200710134824.GK12769@casper.infradead.org>
 <20200710134932.GA16257@infradead.org>
 <20200710135119.GL12769@casper.infradead.org>
 <CA+1E3rKOZUz7oZ_DGW6xZPQaDu+T5iEKXctd+gsJw05VwpGQSQ@mail.gmail.com>
 <CA+1E3r+j=amkEg-_KUKSiu6gt2TRU6AU-_jwnB1C6wHHKnptfQ@mail.gmail.com>
 <20200720171416.GY12769@casper.infradead.org>
 <CA+1E3rLNo5sFH3RPFAM4_SYXSmyWTCdbC3k3-6jeaj3FRPYLkQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 697ee685-469b-4147-7fae-08d82d116481
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2020 00:59:59.5078
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: GEICYzG/tZFpqYr3NnXiuCM/KWc4xxI4A23WKlKc4cxL23fk2Iv31ezFWCu8DJvf3RKge4/kXlx68G1GtvCH1A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR04MB1255
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2020/07/21 5:17, Kanchan Joshi wrote:=0A=
> On Mon, Jul 20, 2020 at 10:44 PM Matthew Wilcox <willy@infradead.org> wro=
te:=0A=
>>=0A=
>> On Mon, Jul 20, 2020 at 10:19:57PM +0530, Kanchan Joshi wrote:=0A=
>>> On Fri, Jul 10, 2020 at 7:41 PM Kanchan Joshi <joshiiitr@gmail.com> wro=
te:=0A=
>>>> If we are doing this for zone-append (and not general cases), "__s64=
=0A=
>>>> res64" should work -.=0A=
>>>> 64 bits =3D 1 (sign) + 23 (bytes-copied: cqe->res) + 40=0A=
>>>> (written-location: chunk_sector bytes limit)=0A=
>>=0A=
>> No, don't do this.=0A=
>>=0A=
>>  struct io_uring_cqe {=0A=
>>         __u64   user_data;      /* sqe->data submission passed back */=
=0A=
>> -       __s32   res;            /* result code for this event */=0A=
>> -       __u32   flags;=0A=
>> +       union {=0A=
>> +               struct {=0A=
>> +                       __s32   res;    /* result code for this event */=
=0A=
>> +                       __u32   flags;=0A=
>> +               };=0A=
>> +               __s64           res64;=0A=
>> +       };=0A=
>>  };=0A=
>>=0A=
>> Return the value in bytes in res64, or a negative errno.  Done.=0A=
> =0A=
> I concur. Can do away with bytes-copied. It's either in its entirety=0A=
> or not at all.=0A=
> =0A=
=0A=
SAS SMR drives may return a partial completion. So the size written may be =
less=0A=
than requested, but not necessarily 0, which would be an error anyway since=
 any=0A=
condition that would lead to 0B being written will cause the drive to fail =
the=0A=
command with an error.=0A=
=0A=
Also, the completed size should be in res in the first cqe to follow io_uri=
ng=0A=
current interface, no ?. The second cqe would use the res64 field to return=
 the=0A=
written offset. Wasn't that the plan ?=0A=
=0A=
-- =0A=
Damien Le Moal=0A=
Western Digital Research=0A=