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: yNPY6jZyFfpNSS4zOMBUrmhTRql6gtivY1nqHOKKhBzjoT5EBNvHJRJsF6EdPS/Yeg3iJ8VVMS
 X297P6MjuYXEuBizcmxerGpFMH6CMYVjChjplE8TpoWZfpAuB2EWeMb8nPmMJd2wppB3GJUcMs
 rI+OVLKwzUN/jaX/SRqJYFgj+qHH8Lh9Qc/1vMLVUlWi5IvsLTv6dB/eHC66A04qGvdzq1yPjT
 aFOMKliYwGm2GwqWihac2VqmOr5fOOJ3zNnlTKIkp8bzgcBbB9P85LVcPbpKHM6IY3bc/JTI6I
 tZk=
From:   Niklas Cassel <Niklas.Cassel@wdc.com>
To:     Damien Le Moal <Damien.LeMoal@wdc.com>
CC:     Jens Axboe <axboe@kernel.dk>,
        Johannes Thumshirn <Johannes.Thumshirn@wdc.com>,
        "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] null_blk: add support for max open/active zone limit
 for zoned devices
Thread-Topic: [PATCH v2] null_blk: add support for max open/active zone limit
 for zoned devices
Thread-Index: AQHWfHkHEFD/cWRr30CMhGnYnEiy+6lNTPiA
Date:   Fri, 28 Aug 2020 10:06:57 +0000
Message-ID: <20200828100655.GA71979@localhost.localdomain>
References: <20200827135018.63644-1-niklas.cassel@wdc.com>
 <CY4PR04MB3751526DC5833902749EBE48E7520@CY4PR04MB3751.namprd04.prod.outlook.com>
In-Reply-To: <CY4PR04MB3751526DC5833902749EBE48E7520@CY4PR04MB3751.namprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2E471980F2C600478E566C98E3404385@namprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 257178c7-0ac9-482e-03a3-08d84b3a1960
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2020 10:06:57.6415
 (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: +BMPKpL5LUp04GzNbeItN7tSaR5ynWEDetDux6adzSrd7kh5VrDyhApkCMWrVKWCZcoOcFFhNzUbUROOGiAHtg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR04MB5204
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 Fri, Aug 28, 2020 at 07:06:26AM +0000, Damien Le Moal wrote:
> On 2020/08/27 22:50, Niklas Cassel wrote:
> > Add support for user space to set a max open zone and a max active zone
> > limit via configfs. By default, the default values are 0 =3D=3D no limi=
t.
> >=20
> > Call the block layer API functions used for exposing the configured
> > limits to sysfs.
> >=20
> > Add accounting in null_blk_zoned so that these new limits are respected=
.
> > Performing an operating that would exceed these limits results in a
>=20
> Performing a write operation that would result in exceeding these...
>=20
> > standard I/O error.
> >=20

It is not only a write operation, also e.g. open zone operation.
However I will s/Performing an operating/Performing an operation/

> > +/*
> > + * This function matches the manage open zone resources function in th=
e ZBC standard,
> > + * with the addition of max active zones support (added in the ZNS sta=
ndard).
> > + *
> > + * The function determines if a zone can transition to implicit open o=
r explicit open,
> > + * while maintaining the max open zone (and max active zone) limit(s).=
 It may close an
> > + * implicit open zone in order to make additional zone resources avail=
able.
> > + *
> > + * ZBC states that an implicit open zone shall be closed only if there=
 is not
> > + * room within the open limit. However, with the addition of an active=
 limit,
> > + * it is not certain that closing an implicit open zone will allow a n=
ew zone
> > + * to be opened, since we might already be at the active limit capacit=
y.
> > + */
> > +static bool null_manage_zone_resources(struct nullb_device *dev, struc=
t blk_zone *zone)
>=20
> I still do not like the name. Since this return a bool, what about
> null_has_zone_resources() ?

I also don't like the name :)

However, since the ZBC spec, in the descriptions of "Write operation, Finis=
h
operation, and Open operation", says that the "manage open zone resources"
function must be called before each of these operations are performed,
and that there is a section that defines how the "manage open zone resource=
s"
is defined, I was thinking that having a similar name would be of value.

And I agree that it is weird that it returns a bool, but that is how it is
defined in the standard.

Perhaps it should have exactly the same name as the standard, i.e.
null_manage_open_zone_resources() ?

However, if you don't think that there is any point of trying to have
a similar name to the function in ZBC, then I will happily rename it :)


Kind regards,
Niklas=