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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 097F3C43334 for ; Wed, 6 Jul 2022 16:39:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229780AbiGFQjv (ORCPT ); Wed, 6 Jul 2022 12:39:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35002 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232753AbiGFQju (ORCPT ); Wed, 6 Jul 2022 12:39:50 -0400 Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 107AD1AD8F for ; Wed, 6 Jul 2022 09:39:50 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id ck6so18996159qtb.7 for ; Wed, 06 Jul 2022 09:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=fa4nx9soOqKJibdgUXA8pSzFsCLLBXgJvJKDXcrmDzk=; b=BA8GuQ8o60halp6kBi7QCLJv4biXC2Sk6LIP173bmoCpH+CRvjWgPweOHCDR8gZnv/ xZOVhdXXRlzHo6W0axc/t8HYfV1IfUgtbHvcHShSYkgPPbUvq8A6KlXXg6XUW2Mzwlug 9O1QHpgR8DHgUbDVzp6juLKg41mOXdWAxCudDW2dq1g2z1PpS0BGW69g4ES/CXfmzhHo 7Ie/6JCYmv3RaYgem8iQ5acl1jOk1p5gBbr4qSK8VJmH1yksI5jaaKZoWoL2bF2TeXP+ 0QXZU0uzp7KetFOsnDzlZC+nlJ8arV/00p9GFsxJWdzhwkJVoWJtoGE0P78JIT9VMlkx txpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=fa4nx9soOqKJibdgUXA8pSzFsCLLBXgJvJKDXcrmDzk=; b=TcCPg8ROg6bKfWN+Sv4EKIlKNEfgR3iej3Qb1i/leoN8x1FbsGSFJvszc3ZGPCCyo4 FkZKF0qb5MZHZ0VWZl9Ko0bG446ciJCHBQfMvDPN0+vN1jkr2qCkf80ch5Puh8xWuMwH DPAPJc99soGBdRvCB0VbB2Q6I2FEq/dEgPltsDOxj9F30ElYnsMoRE4HHPEaLv+H9z1a RP9jNGCJ4xvi3WoFXKEewNnzqZwlrvC0kUOQLknGG76qA3DLuOzrvhCAEzKsaduv9jy0 JwtLBuiJ7jS07uH6i5SEQEpTufdPB7UgUNdlWfhUqzx82Z9qdT8NwV+44WiMNIrTYJum mhsw== X-Gm-Message-State: AJIora9BL0uRVUZBWdre6iyjGPXudipr2fG4l850VpLWJfscwtgNZNt3 CKSHDpLzEbknnNTUIMMUQDRZ/w== X-Google-Smtp-Source: AGRyM1tnYQbvpUd2z7uxCRh7AGVvPT6cQJUaz6AV/kKTVRPPtLVvKqtV/Ro2E17qaLyu4IlL3SlIVg== X-Received: by 2002:a05:622a:1449:b0:31a:daa0:e0b8 with SMTP id v9-20020a05622a144900b0031adaa0e0b8mr33777651qtx.539.1657125589216; Wed, 06 Jul 2022 09:39:49 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-162-113-129.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.113.129]) by smtp.gmail.com with ESMTPSA id q15-20020ac8450f000000b003177f0fb61esm23581858qtn.75.2022.07.06.09.39.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Jul 2022 09:39:48 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1o9844-00772H-1e; Wed, 06 Jul 2022 13:39:48 -0300 Date: Wed, 6 Jul 2022 13:39:48 -0300 From: Jason Gunthorpe To: haris iqbal Cc: "Pearson, Robert B" , "linux-rdma@vger.kernel.org" , "zyjzyj2000@gmail.com" , "aleksei.marov@ionos.com" , "leon@kernel.org" , "haris.iqbal@ionos.com" , "jinpu.wang@ionos.com" , "rpearsonhpe@gmail.com" Subject: Re: [PATCH] RDMA/rxe: For invalidate compare keys according to the MR access Message-ID: <20220706163948.GL23621@ziepe.ca> References: <20220629164946.521293-1-haris.phnx@gmail.com> <20220629183445.GV23621@ziepe.ca> <20220629184432.GW23621@ziepe.ca> <20220705135959.GG23621@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On Wed, Jul 06, 2022 at 05:41:08AM +0200, haris iqbal wrote: > On Tue, Jul 5, 2022 at 4:00 PM Jason Gunthorpe wrote: > > > > On Tue, Jul 05, 2022 at 11:28:59AM +0200, haris iqbal wrote: > > > On Wed, Jun 29, 2022 at 8:48 PM Pearson, Robert B > > > wrote: > > > > > > > > > > > If the rkey's and lkeys are always the same why do we store them twice in the mr ? > > > > > > > > > > > > They are not always the same currently. If you request remote access they are the same if you don't rkey is set to zero. > > > > > > You could, of course, check both the keys and the access bits but that is not the way it is written currently. > > > > > > > > > Storing the rkey instead of checking the flags seems like a weird obfuscation to me.. > > > > > > > > > Jason > > > > > > > > One always has the choice to always just use the lkey and check the flags. But referring the rkey just uses one memory reference 😊 > > > > > > Have we reached a consensus here as to how to solve this? > > > > > > This (and the issue created by dual map) has basically caused a > > > regression in RTRS since the 5.15. And we would appreciate it a lot if > > > the fix goes in and is backported. > > > > I think your patch is close, it should just be tweaked a bit. > > I couldn't conclude from the conversation above what that tweak should > be, if a conclusion has been reached. If not, then I'll wait. The 'rkey' input can be an lkey or rkey, and in rxe the lkey or rkey have the same value, including the variant bits. So, don't check based on the flags, if the rkey is not 0 check it, otherwise check the lkey Since we already did a lookup on the non-varient bits to get this far, the check's only purpose is to confirm that the wqe has the correct variant bits. Jason