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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 23429C48BC4 for ; Tue, 20 Feb 2024 22:36:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:Cc:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=CnaRw0RGGwg8pXGgTNkk+Fqny+BYfp+oDZQFbVfWqvo=; b=vfJ+r5JtMVJbdo djlJHaREmvjB4GQ+AZil+UX004vdfKFZJ1PeRtS6JQSJXpu563NbNKC2CcjonmXn0DTGjhkZQwX3Z x/HVspqHXvSxEmcM48HNQnHgEB1uizMBmlK8qRVxGgcZCW7kjO2248HCbNDQDmOksPfygZeYw78fV +qOXLje83QGuK0A30UimT6eqSQWnaPXH+okOEN+4NfYCGE7OPwlSDeYy4g2kHDp4fCUpySDhOH2+O ZDU115nMeDASYDnCI9JciRBEdjIzI9+gLYz8065ggb1J+ZENNLlbA2xI43l100IL5OPpJhf+Hkm8r p7v534narUP3Exqp8E/w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rcYjG-0000000GNLL-0nf0; Tue, 20 Feb 2024 22:36:46 +0000 Received: from pi.codeconstruct.com.au ([203.29.241.158] helo=codeconstruct.com.au) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rcYjD-0000000GNKd-0qrv for linux-arm-kernel@lists.infradead.org; Tue, 20 Feb 2024 22:36:44 +0000 Received: from [192.168.68.112] (ppp14-2-85-8.adl-apt-pir-bras31.tpg.internode.on.net [14.2.85.8]) by mail.codeconstruct.com.au (Postfix) with ESMTPSA id 0932F20154; Wed, 21 Feb 2024 06:36:31 +0800 (AWST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeconstruct.com.au; s=2022a; t=1708468595; bh=bAguqTpdGJckXBQC6UU/JtFufFB52QFTiS2nWxrqpUE=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=JvGHSM+XE/LFqrPlzs/radD0aS5koT/XXbKC+5mTXe6+C84/j1oB2KyYI2nZwlYcB bp0GCyOYK7oE0hvZP9pDKJg6jFPISq8gptEe53VmSFw2nT+R6C2q+S5rwgso7w87Rq bX6rpccgD0aXvwZOCqE4qYRId4gfSVGRgAAKcqbnr6zc877YGcMr7/naV9GJ4tht7g 1lP+viKKdNCuLBlek3PBk1ecAcok8YyyM2Boc6dVAKt5xBWvSP7dwPWMoYS9bjFHEv H5AOrsTAhvieHyiaQMpFIq2s3BeXvfcoLlniTVsitjUZu8B17CfSAGcdF16ulYzxy9 YWgbPXnt01tvw== Message-ID: <9680ad7d7a48fc36a0572dc2286a1229a29341fe.camel@codeconstruct.com.au> Subject: Re: [PATCH] ipmi: kcs: Update OBF poll timeout to reduce latency From: Andrew Jeffery To: minyard@acm.org, Paul Menzel Cc: Andrew Geissler , joel@jms.id.au, openipmi-developer@lists.sourceforge.net, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org, openbmc@lists.ozlabs.org, Andrew Geissler Date: Wed, 21 Feb 2024 09:06:29 +1030 In-Reply-To: References: <20240220123615.963916-1-geissonator@gmail.com> User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240220_143643_475544_A0052B2E X-CRM114-Status: GOOD ( 34.35 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 2024-02-20 at 13:33 -0600, Corey Minyard wrote: > On Tue, Feb 20, 2024 at 04:51:21PM +0100, Paul Menzel wrote: > > Dear Andrew, > > > > > > Thank you for your patch. Some style suggestions. > > > > Am 20.02.24 um 13:36 schrieb Andrew Geissler: > > > From: Andrew Geissler > > > > (Oh no, Yahoo. (ignore)) > > > > You could be more specific in the git commit message by using *Double*: > > > > > ipmi: kcs: Double OBF poll timeout to reduce latency > > > > > ipmi: kcs: Double OBF poll timeout to 200 us to reduce latency > > > > > Commit f90bc0f97f2b ("ipmi: kcs: Poll OBF briefly to reduce OBE > > > latency") introduced an optimization to poll when the host has > > I assume that removing that patch doesn't fix the issue, it would only > make it worse, right? Yep. > > > > read the output data register (ODR). Testing has shown that the 100us > > > timeout was not always enough. When we miss that 100us window, it > > > results in 10x the time to get the next message from the BMC to the > > > host. When you're sending 100's of messages between the BMC and Host, > > > > I do not understand, how this poll timeout can result in such an increase, > > and why a quite big timeout hurts, but I do not know the implementation. > > It's because increasing that number causes it to poll longer for the > event, the host takes longer than 100us to generate the event, and if > the event is missed the time when it is checked again is very long. > > Polling for 100us is already pretty extreme. 200us is really too long. > > The real problem is that there is no interrupt for this. I'd also guess > there is no interrupt on the host side, because that would solve this > problem, too, as it would certainly get around to handling the interupt > in 100us. I'm assuming the host driver is not the Linux driver, as it > should also handle this in a timely manner, even when polling. I expect the issues Andrew G is observing are with the Power10 boot firmware. The boot firmware only polls. The runtime firmware enables interrupts. > > If people want hardware to perform well, they ought to design it and not > expect software to fix all the problems. +1 > > The right way to fix this is probably to do the same thing the host side > Linux driver does. It has a kernel thread that is kicked off to do > this. Unfortunately, that's more complicated to implement, but it > avoids polling in this location (which causes latency issues on the BMC > side) and lets you poll longer without causing issues. In Andrew G's case he's talking MCTP over KCS using a vendor-defined transport binding (that also leverages LPC FWH cycles for bulk data transfers)[1]. I think it could have taken more inspiration from the IPMI KCS protocol: It might be worth an experiment to write the dummy command value to IDR from the host side after each ODR read to signal the host's clearing of OBF (no interrupt for the BMC) with an IBF (which does interrupt the BMC). And doing the obverse for the BMC. Some brief thought suggests that if the dummy value is read there's no need to send a dummy value in reply (as it's an indicator to read the status register). With that the need for the spin here (or on the host side) is reduced at the cost of some constant protocol overhead. [1]: https://github.com/openbmc/libmctp/blob/master/docs/bindings/vendor-ibm-astlpc.md Andrew J _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel