Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp2377382rwl; Thu, 13 Apr 2023 05:50:50 -0700 (PDT) X-Google-Smtp-Source: AKy350YhFIygMt9AtYCEIpIeTkFTWY8gyWx1ox4Un+a3B5bSV9bK37OARbJ/O+V269g7j/JYMgzK X-Received: by 2002:a17:902:daca:b0:1a6:87f7:2dbf with SMTP id q10-20020a170902daca00b001a687f72dbfmr2481805plx.62.1681390249834; Thu, 13 Apr 2023 05:50:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681390249; cv=none; d=google.com; s=arc-20160816; b=zwTEkuG/hnNWLLZUhhND4bF5kbAxntPD/ycInx4W+xrmp1swS4bNW8P2qoiUcNjVhq eLi9XWjapCkEhta0zHjVgcXgLjrLP+PtJZaNUy+d38+vDAyjC7Ebh2DE5HHnPw389P3O ln+AzfM4k5nsap4VPnD/eLiNdSD6yBvOmbvc1M7nz/ndJMUmyUkuDHjI+lsqr0e91kbV 1LAXKCIVD/53/qcyaeTYGjWnct/EC1lIj332Plr3amwB1fTTv7zlt5YB/ITjpmk+QjpX weu7KBsXr0nOA96DlkoIHip8mg498qknWjtNnam/PfXJov3QZhfaVCLNNF+B+qYwXZL9 NuLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Eo3ABM5zWQmMhLibVU0BIVMukofpyyJ4BJNzzvUnmsY=; b=hGTegxuMScQAHviUKZkAu0Z3xVSQB/K6rzR4aewmllfSLhHnWvkMjVxJ+X+a370Yn+ v1c+ddFNco29vhCy9PvZHr5vmMhifRne4JdE+g1NedaBP6LiXHq4mLPGVLAQ5ELS2a8H e9xeqDymCYLcCIV+n3yL9sIL1GR+HOb7p4cadlxuASPS/WmlVPoxTimlCEklKwtW+des KlKz74BzHmn0s+siPyk3evcN/qpszCCNpyWNL1c0mq9FU6dD4267yYPShEtdOs0tXhd2 j+aVYyQ1pE3joxuXMlDrAI3PZYXd+mtgNCK8z4CkrinStLS1/fzGulZAwakY5av5g9qb VbvQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="Qgz2dn/N"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cx21-20020a17090afd9500b0024711d63febsi2486255pjb.173.2023.04.13.05.50.38; Thu, 13 Apr 2023 05:50:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="Qgz2dn/N"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229982AbjDMMth (ORCPT + 99 others); Thu, 13 Apr 2023 08:49:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53910 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229917AbjDMMtg (ORCPT ); Thu, 13 Apr 2023 08:49:36 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 822D79741; Thu, 13 Apr 2023 05:49:34 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 19AF76152E; Thu, 13 Apr 2023 12:49:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 00D59C433EF; Thu, 13 Apr 2023 12:49:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681390173; bh=hl2z3VQRd2gHDfpU3684uq8PUQrhWsZX8vPo+MGJYmw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Qgz2dn/NnxJFjaA8hJhGDw5y3Qvg2LkpVx/BTL78zd1lYhH0XU/xKW4unpwHdeAhD eBnKAueNAFNCswdjd0k+ox2m7RVOIgFrnEEtdl8w9YTP2DFqJjBDFlJYY1pHTUn7pY se9Auk2WbgunltG/BzpyckiusXOFDmlFo9wJw+OaypC/4KnwiUua8WZmao7j+txjkp Upo1x4Iv2JY6xvk7f5AZfhndIhD7cBLemsOqPLlZgrEGq1b5L1Zew1fWQrDgUcwJGu aqmfIG/MbsVrdPoHXho4hkUQr8ppCMwyZBO5ZvTSGgSEkDS+PvWBnQGhoIY6j3rzp2 J7wBzn5/amvYA== Date: Thu, 13 Apr 2023 15:49:29 +0300 From: Leon Romanovsky To: Jacob Keller Cc: Jason Gunthorpe , Avihai Horon , Aya Levin , Eric Dumazet , Jakub Kicinski , linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, Meir Lichtinger , Michael Guralnik , netdev@vger.kernel.org, Paolo Abeni , Saeed Mahameed , Shay Drory Subject: Re: [PATCH rdma-next 0/4] Allow relaxed ordering read in VFs and VMs Message-ID: <20230413124929.GN17993@unreal> References: <7c5eb785-0fe7-e0e5-8232-403e1d3538ac@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c5eb785-0fe7-e0e5-8232-403e1d3538ac@intel.com> X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 11, 2023 at 04:21:09PM -0700, Jacob Keller wrote: > > > On 4/11/2023 7:01 AM, Jason Gunthorpe wrote: > > On Mon, Apr 10, 2023 at 04:07:49PM +0300, Leon Romanovsky wrote: > >> From: Leon Romanovsky > >> > >> From Avihai, > >> > >> Currently, Relaxed Ordering (RO) can't be used in VFs directly and in > >> VFs assigned to QEMU, even if the PF supports RO. This is due to issues > >> in reporting/emulation of PCI config space RO bit and due to current > >> HCA capability behavior. > >> > >> This series fixes it by using a new HCA capability and by relying on FW > >> to do the "right thing" according to the PF's PCI config space RO value. > >> > >> Allowing RO in VFs and VMs is valuable since it can greatly improve > >> performance on some setups. For example, testing throughput of a VF on > >> an AMD EPYC 7763 and ConnectX-6 Dx setup showed roughly 60% performance > >> improvement. > >> > >> Thanks > >> > >> Avihai Horon (4): > >> RDMA/mlx5: Remove pcie_relaxed_ordering_enabled() check for RO write > >> RDMA/mlx5: Check pcie_relaxed_ordering_enabled() in UMR > >> net/mlx5: Update relaxed ordering read HCA capabilities > >> RDMA/mlx5: Allow relaxed ordering read in VFs and VMs > > > > This looks OK, but the patch structure is pretty confusing. > > > > It seems to me there are really only two patches here, the first is to > > add some static inline > > > > 'mlx5 supports read ro' > > > > which supports both the cap bits described in > > the PRM, with a little comment to explain that old devices only set > > the old cap. > > > > And a second patch to call it in all the places we need to check before > > setting the mkc ro read bit. > > > > Maybe a final third patch to sort out that mistake in the write side. > > > > But this really doesn't have anything to do with VFs and VMs, this is > > adjusting the code to follow the current PRM because the old one was > > mis-desgined. > > > > Jason > > FWIW I think Jason's outline here makes sense too and might be slightly > better. However, reading through the series I was reasonably able to > understand things enough that I think its fine as-is. > > In some sense its not about VF or VM, but fixing this has the result > that it fixes a setup with VF and VM, so I think thats an ok thing to > call out as the goal. VF or VM came from user perspective of where this behavior is not correct. Avihai saw this in QEMU, so he described it in terms which are more clear to the end user. Thanks