From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7ECC6C432C2 for ; Thu, 26 Sep 2019 09:56:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 518052053B for ; Thu, 26 Sep 2019 09:56:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="pEYTOCcm" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726358AbfIZJ4C (ORCPT ); Thu, 26 Sep 2019 05:56:02 -0400 Received: from mail-oi1-f193.google.com ([209.85.167.193]:38512 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726318AbfIZJ4C (ORCPT ); Thu, 26 Sep 2019 05:56:02 -0400 Received: by mail-oi1-f193.google.com with SMTP id m16so1556732oic.5; Thu, 26 Sep 2019 02:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g7QiJenNKxBa3/26UANfbTTYekrIvyL4x477K5pCRuA=; b=pEYTOCcm1DEqg3InE5EGDE7EUod3egkoekuRL+gIIAx/ENObwO8RJRqKcjgOv5oBZr Y868etL8PzrzwloN89W5ZvdHKzspjhBOIdWfgGF4DL0EaLlwdWtGnzRZlchLrMLZvHAA ZlJQPzHmQs1IX513OPcGQ6PGxcZshGlaodi8GxMXqCi6I5/xmedZsOw2LLGCBj1Ezlay WmW2sqx/HQUz7U5OwMx0f6YB/mDsaPa4u3l5lzm9M7FeGBfmsKCoeS9PVTThO10PV4W/ pxPCsKglBTWirRWF+p0+sEXwD48Tfz4AG1zu/rd1NGGQQy0gjK0urt1NCdML+lCVtVBh PdDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g7QiJenNKxBa3/26UANfbTTYekrIvyL4x477K5pCRuA=; b=ehje4FW1alzkaiEbQqYo30pPUKyAdgwY593PuF/AWXHng8PfN8j1mIUJEJ6wswsRui MyH1F7AU5/FuqQhfbOzAwMWCFlH3i+aqpWv0UKFmz37nVeOqs/wZrXsZzu4R0hBIUpnO HMtTKiHYEOagm0Hr5ulLCEmhuKVzX1MEllRFUM5zn+GNXjGfUeteQJy1UnPjLFC9d5g0 mE7FG/vnO/Tu2ZzUrs0J265MrG9ygfn9WdtOfCFvpT/6O2lxnddUvn4jXcyVoCDGfr5L 3gnDDx43DuF6blksjrWCBOOSOB4RLX1PP4SxCRbJjZmrU2RQC1iV/zwmbjRNpz1DDnrq Ylig== X-Gm-Message-State: APjAAAVbNU7ICSLQDiZ69KPQ2SEquI9VWMboBnHImYEjmR38gOid6gZ0 DnJ0suAmmQgjJhQxBwtIRL8sYn+L0iRq6Q+k1xE= X-Google-Smtp-Source: APXvYqzNH1fW9xKBKe6Z3YY60fwvZHmm384uLRC+kPxdxa6fbO3MLQW251lNrni7PIHWCYhj91MQpvFQr1LACnvcfHo= X-Received: by 2002:aca:3ed7:: with SMTP id l206mr1944265oia.25.1569491761364; Thu, 26 Sep 2019 02:56:01 -0700 (PDT) MIME-Version: 1.0 References: <20190620150337.7847-1-jinpuwang@gmail.com> <20190620150337.7847-18-jinpuwang@gmail.com> <5c5ff7df-2cce-ec26-7893-55911e4d8595@acm.org> <6f677d56-82b3-a321-f338-cbf8ff4e83eb@acm.org> In-Reply-To: From: Roman Penyaev Date: Thu, 26 Sep 2019 11:55:50 +0200 Message-ID: Subject: Re: [PATCH v4 17/25] ibnbd: client: main functionality To: Danil Kipnis Cc: Bart Van Assche , Jack Wang , linux-block@vger.kernel.org, linux-rdma@vger.kernel.org, Jens Axboe , Christoph Hellwig , Sagi Grimberg , Jason Gunthorpe , Doug Ledford , rpenyaev@suse.de, Jack Wang Content-Type: text/plain; charset="UTF-8" Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Thu, Sep 26, 2019 at 12:26 AM Danil Kipnis wrote: > > On Wed, Sep 18, 2019 at 5:47 PM Bart Van Assche wrote: > > Combining multiple queues (a) into a single queue (b) that is smaller > > than the combined source queues without sacrificing performance is > > tricky. We already have one such implementation in the block layer core > > and it took considerable time to get that implementation right. See e.g. > > blk_mq_sched_mark_restart_hctx() and blk_mq_sched_restart(). > > Roma, can you please estimate the performance impact in case we switch to it? As I remember correctly I could not reuse the whole machinery with those restarts from block core because shared tags are shared only between hardware queues, i.e. different hardware queues share different tags sets. IBTRS has many hardware queues (independent RDMA connections) but only one tags set, which is equally shared between block devices. What I dreamed about is something like BLK_MQ_F_TAG_GLOBALLY_SHARED support in block layer. -- Roman