Received: by 10.213.65.68 with SMTP id h4csp799475imn; Wed, 4 Apr 2018 07:29:11 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+6PRoaE0I03hF1ibf6eFWFi/uvYlM28R7Zr2HnroFG1rWzxFX54KCcQE2OwLaTY9p96vZb X-Received: by 10.99.120.3 with SMTP id t3mr12016627pgc.56.1522852151628; Wed, 04 Apr 2018 07:29:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522852151; cv=none; d=google.com; s=arc-20160816; b=pbDxBUNeRqFKsN90P49uYaPwIoBSBBMPhx2XlJW76IJ0VcWimcxrCd/s2mHtNDpz18 soGwcR+dBlkw3Fz0EjdukM5OCkiISM+xsJtNlvfKaKfC0G35OgZK7vdKC5HrKfwgHpWL Q0xezKCBnzYEDxjbf+tAkgSkAtbxw30ZcVE22PRLdPdr38bt1UaoApzevwgGpL/mXN+y GRhvztPFmnzfOd559DawW6vs8yfnhWeN15EjWUkn77Xg7QHMfmxl9tNVGfVAO9VPeTgK kxPBVKzRwnTsnrMZtwk0ILdiSYVnMVlG/0bTX5Qh4rYnC64h3Dkk5Lp4ZcASQrAME2MY iRpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=e5W1IsA+g9SsHx50jvDjWHfygnRl7yx5h+Szw5DdTXU=; b=mAsL3+o0X1+32Qq14yCZ7MEiC/sR+nAgVsh+evXft4ohe9lIwofV1qLEu8p1PbhmBb M9TG6jFzy6X/q//URQN7Nhu+IrIrAbVM9AOjY6LVcUWW6SqR7qBegDSAln69FuWaMteA YoHElALf/sYswWhUrdtl1VzexP4j5VA8uoN6VTuvKQNME3Q2DVJTY9t8Ineb1aIHuxsM r1acc6OkzuufZuJIYRy5Hwdrv52uhwMmStIUzjFz658FFuNuDl946mpaPMLcPizhirmo VGv9a1sBFgQg7mEynzn98bcupZLRJcbAQZuXHhE9MFdJYPtikqtoZSsQ4DXR7hJs0oPC cs5Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m72si4181256pfi.236.2018.04.04.07.28.57; Wed, 04 Apr 2018 07:29:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751272AbeDDO1s (ORCPT + 99 others); Wed, 4 Apr 2018 10:27:48 -0400 Received: from mga02.intel.com ([134.134.136.20]:63393 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751167AbeDDO1r (ORCPT ); Wed, 4 Apr 2018 10:27:47 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2018 07:27:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,406,1517904000"; d="scan'208";a="30650430" Received: from unknown (HELO localhost.localdomain) ([10.232.112.44]) by orsmga007.jf.intel.com with ESMTP; 04 Apr 2018 07:27:46 -0700 Date: Wed, 4 Apr 2018 08:30:27 -0600 From: Keith Busch To: "Eric H. Chang" Cc: Christoph Hellwig , Baegjae Sung , "axboe@fb.com" , "sagi@grimberg.me" , "linux-nvme@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] nvme-multipath: implement active-active round-robin path selector Message-ID: <20180404143027.GE4485@localhost.localdomain> References: <20180327043851.6640-1-baegjae@gmail.com> <20180328080646.GB20373@lst.de> <20180328194741.GJ13039@localhost.localdomain> <20180330070651.GA17095@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 30, 2018 at 09:04:46AM +0000, Eric H. Chang wrote: > We internally call PCIe-retimer as HBA. It's not a real Host Bus Adapter that translates the interface from PCIe to SATA or SAS. Sorry for the confusion. Please don't call a PCIe retimer an "HBA"! :) While your experiment is setup to benefit from round-robin, my only concern is it has odd performance in a real world scenario with IO threads executing in different nodes. Christoph's proposal will naturally utilize both paths optimally there, where round-robin will saturate node interlinks. Not that I'm against having the choice; your setup probably does represent real use. But if we're going to have multiple choice, user documentation on nvme path selectors will be useful here.