Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp231927pxb; Mon, 16 Aug 2021 04:21:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzbeAP5KXuZ5j8Cc6NjD2O6AtstLySZfIUeVJqzgtEtVUJcp9b5vTuBm1Ugl768KJXvoUob X-Received: by 2002:a17:906:2cd5:: with SMTP id r21mr12149751ejr.435.1629112885648; Mon, 16 Aug 2021 04:21:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629112885; cv=none; d=google.com; s=arc-20160816; b=VETDKc5DUt6rIdFSMgWFI4zUaC+yrCI6iq9VUYsShgsq5cfBnUooMeGzGdbeRN2qxq GbhpcHRwGIKygDci62PmJ7xCfYPYVyLLYTTNXQmcWeqP7Lv8M/S0cT/JOdc6XKwwPixh GkjP2dMKceUVoH1PKD42UE42qWxDDzmYeFkKrO6UI40BtsDZ7BTFRO+LaxBpNiHXVzpE GpGMgrwg+SD/+Okodtlz1XIfDOpfH8Xyf3EfcnLaVRbq/zWo2E/CpiME4JLP1ceGsuQo pQ0c5qXfCcFjZSKKC49y2WEt5EVCPyQQHuhmlgS9XYE+RrOneT/XCom9eCFZu0XFQ1d1 Kwuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:in-reply-to:date:sender:references:subject:cc:to:from :dkim-signature:dkim-filter; bh=jom1m2zV0A64UbIJZMq9VLdri6bu1FYEMPAJTzg5Phg=; b=h4WfBiYgQO03Xyy4cIDJBnaWYbCgjVXBUeW0vu/+W998EzMPyINd1ihOHAAOHoZOaP s/YJ1H10bZx0qCeUjxscuYGyzynJPRpk78bXo/sYLym/Y6ONZ63oiRGc6IFFgEGFxxf6 vKGrhlzgjwltdCq7Xkb7wMYun+fHFhy/w63Vl4UtjcA4hhPgoM9OWZID3WvuUMengw6N lqZEt32mQAHNXeow7+Y89hOSB3UVk1GYIBUyRX+tjFY7TDtfQgw3OaYz48H7IxGYzzpR UyZGvSq/w04gU3tGHDgc3CGVkuGeywRt1uCnyCfCoGqnvA1Rglk+P/W5m7TT1pmjYw7w mkSw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@piap.pl header.s=mail header.b="dYvD/qzb"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=piap.pl Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v25si5967477edx.72.2021.08.16.04.21.03; Mon, 16 Aug 2021 04:21:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@piap.pl header.s=mail header.b="dYvD/qzb"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=piap.pl Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236083AbhHPLTE (ORCPT + 99 others); Mon, 16 Aug 2021 07:19:04 -0400 Received: from ni.piap.pl ([195.187.100.5]:46120 "EHLO ni.piap.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231143AbhHPLTD (ORCPT ); Mon, 16 Aug 2021 07:19:03 -0400 Received: from t19.piap.pl (OSB1819.piap.pl [10.0.9.19]) by ni.piap.pl (Postfix) with ESMTPSA id 3498FC3F2A57; Mon, 16 Aug 2021 13:18:30 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 ni.piap.pl 3498FC3F2A57 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=piap.pl; s=mail; t=1629112710; bh=jom1m2zV0A64UbIJZMq9VLdri6bu1FYEMPAJTzg5Phg=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=dYvD/qzboATUDqZDtrhBSDNnQV6eV9SgQUQU8sIg5yw2TjlndYDs1E49SdciIru6+ I6bfUznjxZB8z7nFJF1avTVkyQqVfFumLpYf0cjiwvZa17VY4myCm9ZM9tyKD+NKz3 22q9yeLlaPr5JLCCmUpDZarcon8kRlJ2622gOtGE= From: =?utf-8?Q?Krzysztof_Ha=C5=82asa?= To: Richard Zhu Cc: Bjorn Helgaas , Krzysztof =?utf-8?Q?Wilczy=C5=84s?= =?utf-8?Q?ki?= , Bjorn Helgaas , "linux-pci@vger.kernel.org" , Artem Lapkin , Neil Armstrong , Huacai Chen , Rob Herring , Lorenzo Pieralisi , Lucas Stach , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] PCIe: limit Max Read Request Size on i.MX to 512 bytes References: <20210813192254.GA2604116@bjorn-Precision-5520> Sender: khalasa@piap.pl Date: Mon, 16 Aug 2021 13:18:30 +0200 In-Reply-To: (Richard Zhu's message of "Mon, 16 Aug 2021 07:49:52 +0000") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 165577 [Aug 16 2021] X-KLMS-AntiSpam-Version: 5.9.20.0 X-KLMS-AntiSpam-Envelope-From: khalasa@piap.pl X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Auth: dkim=pass header.d=piap.pl X-KLMS-AntiSpam-Info: LuaCore: 454 454 39c6e442fd417993330528e7f9d13ac1bf7fdf8c, {Tracking_marketers, three}, {Tracking_from_domain_doesnt_match_to}, 127.0.0.199:7.1.2;piap.pl:7.1.1;t19.piap.pl:7.1.1;d41d8cd98f00b204e9800998ecf8427e.com:7.1.1 X-MS-Exchange-Organization-SCL: -1 X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiPhishing: Clean, bases: 2021/08/16 10:32:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2021/08/15 23:54:00 #17042267 X-KLMS-AntiVirus-Status: Clean, skipped Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Richard, Please correct me if I got something wrong: > Regarding my understanding, that there should be decomposition operations= if the > Max_Read_Request_Size is larger than the Max_Payload_size specified > by RC port. I think this means that, for example, a memory read request (a single short physical TLP packet on PCIe, from the peripheral device to the CPU) can request more data than Max_Payload_size (128 bytes on i.MX6). In such case, up to 4 "completion" physical TLP packets are returned by the CPU (up to 512 bytes, with each individual TLP up to 128 bytes as per Max_Payload_size). The device can't request more than 512 bytes, though - the CPU would not service such request. > The bit0 of AMBA Multiple Outbound Decomposed NP Sub-Requests Control Reg= ister(Offset:0x700 + 0x24) > had been set to be 1b1 in default. > > Note: The description of this bit. > Enable AMBA Multiple Outbound Decomposed NP Sub- Requests. > This bit when set to '0' disables the possibility of having multiple outs= tanding non-posted requests that > were derived from decomposition of an outbound AMBA request. See Supporte= d AXI Burst Operations for > more details. I think the above means that - when I disable the bit in question - I can't issue memory read requests longer than 128 bytes (max payload size). This is not exactly clear to me: > You should not clear this register unless your application master is > requesting an amount of read data greater than Max_Read_Request_Size, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Is "completing" such a request at all possible? The device shouldn't request more data than its (not CPU's) Max_Read_Request_Size. I. e. if 512 is written to RTL8111's Max_Read_Request_Size, then the Realtek chip will request max 512 bytes at a time. > and the remote device (or switch) is reordering completions that have > different tags Fortunately, such completions don't seem to be reordered. However, I'm not sure how setting a bit in the CPU registers could help here. I think the only way *IF* the completions were reordered would be setting MRRS =3D MPS (=3D 128 bytes on i.MX6) - so there is nothing that could be reordered. --=20 Krzysztof "Chris" Ha=C5=82asa Sie=C4=87 Badawcza =C5=81ukasiewicz Przemys=C5=82owy Instytut Automatyki i Pomiar=C3=B3w PIAP Al. Jerozolimskie 202, 02-486 Warszawa