From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Reinecke Subject: Re: [LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path? Date: Wed, 13 Jan 2016 09:21:24 +0100 Message-ID: <56960904.5060006@suse.de> References: <20160112185947.GA29176@redhat.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: device-mapper development , Mike Snitzer Cc: linux-block@vger.kernel.org, lsf-pc@lists.linux-foundation.org List-Id: dm-devel.ids On 01/13/2016 12:39 AM, Mikulas Patocka wrote: > > > On Tue, 12 Jan 2016, Mike Snitzer wrote: > >> Hi, >> >> I'd like to attend LSF/MM and as the subject covers I'd like to at least >> participate in a discussion about plans (realistic or not) for >> removing/deprecating the old .request_fn path in block core and block >> drivers. >> >> The request-based DM code (only used for multipath) has gotten more >> complex to support both old .request_fn and blk-mq (and stacking >> combinations: .request_fn ontop of blk-mq paths, blk-mq ontop of >> .request_fn paths). Simplifying DM core in this area would be nice. >> >> One of the hurdles has been blk-mq doesn't yet have a scheduler. I know >> Jens had/has something in the works. But there is also the question of >> whether DM's top-level blk-mq request_queue should be trained to >> leverage/stack underlying blk-mq request_queue capabilities (Keith Busch >> was going to look at this aspect in the context of multipath on NVMe but >> I never heard anything from Keith on that). As of now DM multipath's >> blk-mq request_queue only supports a single (virtual) hw queue. >> >> In addition to the above topic, I'd be open to discussing Linux MD >> maintainership options with others if for some reason that is still an >> unresolved situation come mid April. >> >> Thanks, >> Mike > > Convert multipath from request-based to bio-based and these problems in > device mapper core will disappear :-) > We have been down that road already. It doesn't work. There is a reason why we switched to request-based multipathing. Cheers, Hannes -- = Dr. Hannes Reinecke Teamlead Storage & Networking hare@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N=FCrnberg GF: F. Imend=F6rffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG N=FCrnberg)