From: Christoph Hellwig <hch@lst.de>
To: Javier Gonzalez <javier@javigon.com>
Cc: Christoph Hellwig <hch@lst.de>,
Kanchan Joshi <joshi.k@samsung.com>,
kbusch@kernel.org, Damien.LeMoal@wdc.com, axboe@kernel.dk,
sagi@grimberg.me, linux-nvme@lists.infradead.org,
linux-kernel@vger.kernel.org, johannes.thumshirn@wdc.com,
Nitesh Shetty <nj.shetty@samsung.com>,
SelvaKumar S <selvakuma.s1@samsung.com>
Subject: Re: [PATCH 2/2] nvme: add emulation for zone-append
Date: Wed, 19 Aug 2020 09:40:35 +0200 [thread overview]
Message-ID: <20200819074035.GA21991@lst.de> (raw)
In-Reply-To: <20200818180428.obipue6adpqqpwjj@MacBook-Pro.localdomain>
On Tue, Aug 18, 2020 at 08:04:28PM +0200, Javier Gonzalez wrote:
> I understand that you want vendor alignment in the NVMe driver and I
> agree. We are not pushing for a non-append model - you can see that we
> are investing effort in implementing the append path in thee block layer
> and io_uring and we will continue doing so as patches get merged.
>
> This said, we do have some OEM models that do not implement append and I
> would like them to be supported in Linux. As you know, new TPs are being
> standardized now and the append emulation is the based for adding
> support for this. I do not believe it is unreasonable to find a way to
> add support for this SSDs.
I do not think we should support anything but Zone Append, especially not
the new TP, which is going to add even more horrible code for absolutely
no good reason.
> If you completely close the door this approach, the alternative is
> carrying off-tree patches to the several OEMs that use these devices.
> This is not good for the zoned ecosystem nor for the future of Zone
> Append.
I really don't have a problem with that. If these OEMs want to use
an inferior access model only, they have to pay the price for it.
I also don't think that proxy arguments are very useful. If you OEMs
are troubled by carrying patches becomes they decided to buy inferior
drivers they are perfectly happy to argue their cause here on the list.
> Are you open to us doing some characterization and if the impact
> to the fast path is not significant, moving ahead to a Zone Append
> emulation like in SCSI? I will promise that we will remove this path if
> requests for these devices terminate.
As said I do not think implementing zone append emulation or the TP that
shall not be named are a good idea for Linux.
next prev parent reply other threads:[~2020-08-19 7:40 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20200818053247epcas5p262c5fd7e207dfa5145011c4329cf239d@epcas5p2.samsung.com>
2020-08-18 5:29 ` [PATCH 0/2] enable append-emulation for ZNS Kanchan Joshi
2020-08-18 5:29 ` [PATCH 1/2] nvme: set io-scheduler requirement " Kanchan Joshi
2020-08-18 7:11 ` Christoph Hellwig
2020-08-19 9:26 ` Kanchan Joshi
2020-08-19 9:38 ` Damien Le Moal
2020-08-19 10:31 ` Kanchan Joshi
2020-08-19 11:17 ` Damien Le Moal
2020-09-07 7:00 ` Kanchan Joshi
2020-09-07 8:22 ` Damien Le Moal
2020-09-07 11:23 ` Kanchan Joshi
2020-09-07 11:37 ` Damien Le Moal
2020-09-07 11:54 ` Kanchan Joshi
2020-09-07 12:53 ` Damien Le Moal
2020-08-18 5:29 ` [PATCH 2/2] nvme: add emulation for zone-append Kanchan Joshi
2020-08-18 7:12 ` Christoph Hellwig
2020-08-18 9:50 ` Javier Gonzalez
2020-08-18 10:51 ` Matias Bjørling
2020-08-18 18:11 ` Javier Gonzalez
2020-08-18 15:50 ` Christoph Hellwig
2020-08-18 18:04 ` Javier Gonzalez
2020-08-19 7:40 ` Christoph Hellwig [this message]
2020-08-19 8:33 ` Javier Gonzalez
2020-08-19 9:14 ` Damien Le Moal
2020-08-19 10:43 ` Christoph Hellwig
2020-08-20 6:45 ` Javier Gonzalez
2020-08-19 10:49 ` Christoph Hellwig
2020-08-18 16:58 ` Keith Busch
2020-08-18 17:29 ` Javier Gonzalez
2020-08-18 17:39 ` Keith Busch
2020-08-18 18:13 ` Javier Gonzalez
2020-08-19 19:11 ` David Fugate
2020-08-19 19:25 ` Jens Axboe
2020-08-19 21:54 ` David Fugate
2020-08-19 22:10 ` Keith Busch
2020-08-19 23:43 ` David Fugate
2020-08-20 3:45 ` Keith Busch
2020-08-20 23:26 ` David Fugate
2020-08-20 5:51 ` Christoph Hellwig
2020-08-20 6:37 ` Javier Gonzalez
2020-08-20 6:52 ` Christoph Hellwig
2020-08-20 8:03 ` Javier Gonzalez
2020-08-19 21:42 ` Keith Busch
2020-08-20 7:37 ` Kanchan Joshi
2020-08-20 8:14 ` Javier Gonzalez
2020-08-20 5:29 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200819074035.GA21991@lst.de \
--to=hch@lst.de \
--cc=Damien.LeMoal@wdc.com \
--cc=axboe@kernel.dk \
--cc=javier@javigon.com \
--cc=johannes.thumshirn@wdc.com \
--cc=joshi.k@samsung.com \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=nj.shetty@samsung.com \
--cc=sagi@grimberg.me \
--cc=selvakuma.s1@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).