Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4193580imm; Wed, 30 May 2018 00:33:21 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKYP7SEKrdLC0KxdXj3x3AVmRQ99DWrzJK5tqn0QmojkYZSM4y8oRm+xNrDsl/ai56CHxMl X-Received: by 2002:a62:568f:: with SMTP id h15-v6mr1699537pfj.131.1527665601477; Wed, 30 May 2018 00:33:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527665601; cv=none; d=google.com; s=arc-20160816; b=KcS++H6VEFJMRwIw2SeteMjV0sni1/gy+SL73KS2rn/Vb5+UX5fOull+AvFNY5xBAx ATayWHpyV7MZA2IcwgW2GsOnrYCddYMj+q/I/q4rdQXS59G9vyE92cJ8RadNiCxyrmT/ Y/jSc02OtfFk/6WGMkhSo267QKEw8Fl3b3LC3yauxp/ggXlQXNIoxgfBZ0AtlzcXYtF6 U6w4dybWn2K7J7yQWtH6gARfcmOXY9rV30Q+bVHe6DLexU5bUNgU5kABCcEbYf9aQ2qn fsTNyAXslmk+OWijLl6LhqS/tBpibNjwng/vYAWiXTEeI2BTW97zfrmL02aYm4WY3Frp Ozkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature:arc-authentication-results; bh=nBCAD4h7X2GTyMecvMMDXi193nhs5s5maHar7B8NRjQ=; b=N93uM3TCKWKfQpjyHdfyzPYt5fRJTKn3ux5kT5dwHSdERUbnT38wWn4oousSZlUtjg KCRtEN2D0BsreP5FyjmRGgKhFElIuanQpGTctXlrAfFLXU573Yrq1KqShOJmqmmwnmA3 oxQ1CKc6jPkh8zhxev9hQbOQKzpDNxK8tErcUWC2j066KkClvWGp5B1jg1RVHnv75b6r 53PdL8+79jkXnAbFYR+TbDX1BIF28yf33TflQQ0TiXOqPjYpTwgbshx6cPArj8GUswN4 3A2BdHRVRD4cVk/qvTb0faOOkTsD17smdqDk+KU2lU22TVJBXIYPKZyH9ouAMXcJ7rhx /0HQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=rWbrYoEf; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b3-v6si33944531plc.14.2018.05.30.00.33.07; Wed, 30 May 2018 00:33:21 -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; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=rWbrYoEf; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935863AbeE3Hcb (ORCPT + 99 others); Wed, 30 May 2018 03:32:31 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:50204 "EHLO aserp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935179AbeE3Hc2 (ORCPT ); Wed, 30 May 2018 03:32:28 -0400 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w4U7UbZX125234; Wed, 30 May 2018 07:32:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=nBCAD4h7X2GTyMecvMMDXi193nhs5s5maHar7B8NRjQ=; b=rWbrYoEfr9wQdO+bBr6v1RCQXsp07DovgjwHZIECi/XeCYU51BqdZ+J013BSqznyGWi7 aAMR0wSmEars9XBR5MrWetgUC0zlbHkRHoEKYVX0tfNbBO4zNQPrLRLRd4YpYMbkB45m k05W6cmnKWmZ2+xD/ygZ5VLS0/bQ5cE559dZj0+9A3UCliY2s0NEsI49YV65pRKiktne lnbJdKF0zWb29GaglSV0yE9BiQGsqLPkmoQKnEzWPLtIzNlNRRUVDN22C8i26ZVeurYc ck51Ic8CVN1LNpIplQTbQx/1kojzvLB9MvPG/SFNrubk2RRVZQo79jrlqaIjTY60Zgct hg== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2120.oracle.com with ESMTP id 2j9ev893gs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 30 May 2018 07:32:10 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w4U7W8GH012244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 30 May 2018 07:32:09 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w4U7W7dW014734; Wed, 30 May 2018 07:32:07 GMT Received: from dhcp-10-172-157-170.no.oracle.com (/10.172.157.170) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 30 May 2018 00:32:07 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: [PATCH] IB/mad: Use ID allocator routines to allocate agent number From: =?utf-8?Q?H=C3=A5kon_Bugge?= In-Reply-To: <20180529164032.GB18457@ziepe.ca> Date: Wed, 30 May 2018 09:32:02 +0200 Cc: Hans Westgaard Ry , Doug Ledford , Jack Morgenstein , Daniel Jurgens , Parav Pandit , Pravin Shedge , OFED mailing list , linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <0E56560E-F577-43A6-9F18-B7AC7B5DB213@oracle.com> References: <20180529073808.27735-1-hans.westgaard.ry@oracle.com> <20180529154922.GA18457@ziepe.ca> <20180529164032.GB18457@ziepe.ca> To: Jason Gunthorpe X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8908 signatures=668702 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=15 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1805300087 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On 29 May 2018, at 18:40, Jason Gunthorpe wrote: >=20 > On Tue, May 29, 2018 at 06:16:14PM +0200, H=C3=A5kon Bugge wrote: >>=20 >>> On 29 May 2018, at 17:49, Jason Gunthorpe wrote: >>>=20 >>> On Tue, May 29, 2018 at 09:38:08AM +0200, Hans Westgaard Ry wrote: >>>> The agent TID is a 64 bit value split in two dwords. The least >>>> significant dword is the TID running counter. The most significant >>>> dword is the agent number. In the CX-3 shared port model, the mlx4 >>>> driver uses the most significant byte of the agent number to store = the >>>> slave number, making agent numbers greater and equal to 2^24 (3 = bytes) >>>> unusable. >>>=20 >>> There is no reason for this to be an ida, just do something like >>>=20 >>> mad_agent_priv->agent.hi_tid =3D = atomic_inc_return(&ib_mad_client_id) & mad_agent_priv->ib_dev->tid_mask; >>>=20 >>> And have the driver set tid_mask to 3 bytes of 0xFF >>=20 >> The issue is that some of the mad agents are long-lived, so you will >> wrap and use the same TID twice. >=20 > We already have that problem, and using ida is problematic because we > need to maximize the time between TID re-use, which ida isn't doing. Initially, I thought that too, but consulted the spec which states: C13-18.1.1: When initiating a new operation, MADHeader:TransactionID shall be set to such a value that within that MAD the combination of = TID, SGID, and MgmtClass is different from that of any other currently = executing operation. [] "currently executing operation" that is. But if timeouts etc. leads to MAD floating around in the fabric, its of = course more robust to maximize the time between reuse. Then idr_alloc_cyclic() can be used. > Preventing re-use seems like a seperate issue from limiting the range > to be compatible with mlx4. Yes. But a v2 of Hans' patch using idr_alloc_cyclic() solves both = issues. Thxs, H=C3=A5kon >=20 > Jason > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" = in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html