From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9B8EE30BB81 for ; Fri, 6 Feb 2026 14:55:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770389729; cv=none; b=iYX0lblvGEyj70VqKsal+FZc3yR+qGjCgDAVTbisl9r/eekk1IGdxYQk1tPlRln+9DUt0r8rr6IcXyAd7E8YIm4tf/FYjkQrrsPuS9mV8wRPzCLjiZGw0x/hd0vTCJlkPrra0LXqP0uvMMbEVBV7x2hKcttmAC4N5S2cL9ccjV8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770389729; c=relaxed/simple; bh=w4gwfpnCmNDKtFsdpn+Fl24IctApZJ7psH9b64M746U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nObs0Xuorn9+RKWwsVc5TDgw0lE1pLKo7CX7EYC+7uEO2ec0CReuKzMvS7nH280bj2QAUk8lwp4fYk0w96qbPG81ftj4m3aiBO8/vWxLFfAS895k1bhC6elewlsXcsyERrxeT4Ud3s85WJVxQOkxPtdF0s3iqX66P3xSnvjAbUs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=X1YTRZSE; arc=none smtp.client-ip=209.85.160.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="X1YTRZSE" Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-502f101d1cfso20511471cf.1 for ; Fri, 06 Feb 2026 06:55:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1770389728; x=1770994528; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=QEVbG+OGHuK+wSRx1ZB0TTnPh8Fd39eaNNr9LKUs9VM=; b=X1YTRZSERGs9Jk5pRRpL+B+nUUChC8tdwROARVRwz4s8vUtaF1Z8LJgkVSjC2UeChQ uZTpzQFgIVkmd7fmt9KBs7FxXVvQX0s8RUDncrxaue+BQN9AZYiCW0Zte8xEOlx5DSzK Z6g07ZObvV8HWCBtlEjUX5sBPjretd79s9w/ml8/59EUp3G7zdDCdU9fjl/loZRm/Dhw S5UT/FRdBC4r6UR0rWvxxiEnpuaaPSAOJNxQNUmhsdS6awhNTZFdV3T0H/o+Rpv+DQL/ 2TVDKSl9yOpB9rRYnwaxs04yI+zBbLVVHSVSFgy87v6CGF+8RF0A5dh62OLG54dzuZE1 5kFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770389728; x=1770994528; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QEVbG+OGHuK+wSRx1ZB0TTnPh8Fd39eaNNr9LKUs9VM=; b=xETsv3HeSwrQZzqGITRyEi9mcVVZhZoIb1XTWtskrKiYUPXBTsF3UKa55tP/bCiXLj bjPsolhBA/HxSXm8JJf8ZP+pjAdSrf1reg/WvQnMpCNYFYQnT31cJTV2uqZFPbEGyprH ultJ2QCahgewNHKjN6Me20bPKdD7RbJu/dfz0RFKi/NU/zR3wm3HqmIDQp2uSCk7PzTp rHDCAtHfeTwq9OerZtAS+c+AobFaYjUipiehEIVHPDa9ECPvnKUhmO6AaHKr9m1M8tH+ RFU/WNxHvS9lG0ddn7Lfa3lYEAqo9t7HMehk/n/FL2fPsQTGnTeCN7WoQmCk8GNHX6f0 3AlQ== X-Forwarded-Encrypted: i=1; AJvYcCUsLTTuGpcS114f59zBKnOwUqxKycuWRpk0RrMT5SnD+Kn1ZU3Aoo3qRM5EbpwsXCheudhiFZdWKa94Sr8=@vger.kernel.org X-Gm-Message-State: AOJu0YyOz6bmY4zTao/I2diHfhTbYfhY09q3YKPuc2Z1PHyK1SFRm89c rx9OgZGQ5NwtqFOjExxzaMa3ZUHIXk/To+vANDxCUr/vRmnggfw0xjdN+tQ0b24lcEupaTkIePc C1j26 X-Gm-Gg: AZuq6aLoVrAM0NTCwRcUikYwzW/9PAqyDOYk6BTe2SwaH1buuABWGWxKQz6TZj/OzUy IuwS2QhUtgmSqeqHtdGCAMh3olgLbjHFOaqRQRzePLx9bCgQMr35zF4n60+mHSFkdh1NOrcHzJp 1lcal7bJtfZr6A4uYOFenM2ZQd4bpaWB/dWeKaU+yy3DPkLkI6D7BNxA6e2kpFD/em+ylgKIcdB /ww1tc2r8tIuDs+uQg+QVz6TFh2pHCpG8hJA8eACzXVp+F1JqTzZEE7cD9T7dP2DQrHMw5UKS2J Fr8OGLPTYuskZUcBYShyzhFPbxJirNQSMK8yOSP4RTbF22QOPSuekWwnIDQznzLUdfhiGt3rXte 3dquHnJ2K2j/rlhwu6nMdd8HrHrACjlVqkO2hfGzdNDt41HPv4Ntff2USJmJ/vRNNUmZp55M+aD Nn/mr6Y4uAI8o8NcsvQ9tZEYjAdKf8zqjWEeK2EuWxafLeR2VlutPnAcyqonTbeod6z88= X-Received: by 2002:a05:622a:514:b0:505:e448:1b10 with SMTP id d75a77b69052e-506399bb207mr36141991cf.41.1770389728337; Fri, 06 Feb 2026 06:55:28 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-112-119.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.112.119]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8953bf59596sm18799476d6.22.2026.02.06.06.55.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Feb 2026 06:55:27 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1voNF1-00000008VuF-0RYM; Fri, 06 Feb 2026 10:55:27 -0400 Date: Fri, 6 Feb 2026 10:55:27 -0400 From: Jason Gunthorpe To: Konstantin Taranov Cc: Leon Romanovsky , Konstantin Taranov , Shiraz Saleem , Long Li , "linux-rdma@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH rdma-next 1/1] RDMA/mana_ib: return PD number to the user Message-ID: <20260206145527.GL943673@ziepe.ca> References: <20260204135813.870538-1-kotaranov@linux.microsoft.com> <20260204142827.GF2328995@ziepe.ca> <20260204174643.GA12824@unreal> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Feb 05, 2026 at 12:03:18PM +0000, Konstantin Taranov wrote: > > > > On Wed, Feb 04, 2026 at 10:28:27AM -0400, Jason Gunthorpe wrote: > > > On Wed, Feb 04, 2026 at 05:58:13AM -0800, Konstantin Taranov wrote: > > > > From: Konstantin Taranov > > > > > > > > Implement returning to userspace applications PDNs of created PDs. > > > > Allow users to request short PDNs which are 16 bits. > > > > > > Why does userspace ever need to see a PDN? Please justify that in the > > > commit message > > > > Probably for the debug and we have restrack for it. > > > > Sure, I will add the explanation in v2. Overall, it is for > applications working on top of the rdma-core (e.g., mana DPDK). The > use-case is similar to what mlx4 and mthca have for address vectors > in rdma-core for isolation. As the whole process of working with > WQs and CQs is implemented in that applications (e.g., mana DPDK), > they need to know PDN to build a correct request. What is more, the > HW folks put a limit of 16 bits to the PDN field, requiring a flag > to ensure that we get a PDN that fits into the field. > > I hope that it justifies the change as most ib providers have pdn in > the user-space. But they don't put it in a WQE and don't check in HW it is exactly the same as the PDN the WQ already has. You have PDs in AHs and other related objects which make sense, but a WQ only has one PD, it is illogical to pass in a PDN in a WQE, because it can never take on a different value. If it can take on a different value then your HW's security model is broken. Jason