From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Tue, 23 Jun 2020 17:24:08 +0200 (CEST) Date: Tue, 23 Jun 2020 11:22:36 -0400 From: Mike Snitzer Message-ID: <20200623152235.GB19657@redhat.com> References: <20200619164132.1648-1-ignat@cloudflare.com> <20200619165548.GA24779@redhat.com> <20200623150118.GA19657@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] [RFC PATCH 0/1] dm-crypt excessive overhead List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ignat Korchagin Cc: Damien Le Moal , Mikulas Patocka , "dm-crypt@saout.de" , "dm-devel@redhat.com" , "linux-kernel@vger.kernel.org" , "agk@redhat.com" , "kernel-team@cloudflare.com" On Tue, Jun 23 2020 at 11:07am -0400, Ignat Korchagin wrote: > Do you think it may be better to break it in two flags: one for read > path and one for write? So, depending on the needs and workflow these > could be enabled independently? If there is a need to split, then sure. But I think Damien had a hard requirement that writes had to be inlined but that reads didn't _need_ to be for his dm-zoned usecase. Damien may not yet have assessed the performance implications, of not have reads inlined, as much as you have. So let's see how Damien's work goes and if he trully doesn't need/want reads to be inlined then 2 flags can be created. Mike