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 3BC90C05027 for ; Sat, 18 Feb 2023 01:16:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229607AbjBRBQL (ORCPT ); Fri, 17 Feb 2023 20:16:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60906 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229461AbjBRBQJ (ORCPT ); Fri, 17 Feb 2023 20:16:09 -0500 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D23AD2528C; Fri, 17 Feb 2023 17:16:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=+ptoffDVYgxt0P2DE5JtekmfBaZOv2MwgelUi56EYdk=; b=CWYL+oFvvItR6oQuAmSJ5lqYhB u+/OAyoKYXzOik3PnH//s4FxRBjbNyCBu8PnPMLfwYq89cLpPOAd/Na8q8Ct1bQu0oG6WGR8XIuAM HykoKy6IObvy4JI8SM/CGVhsOJ343obkV5evGmdFkODl3fSbYNP9vLi6K66HCn49Yh1o=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1pTBpP-005M8A-8X; Sat, 18 Feb 2023 02:15:51 +0100 Date: Sat, 18 Feb 2023 02:15:51 +0100 From: Andrew Lunn To: Wei Fang Cc: Alexander Lobakin , Shenwei Wang , Clark Wang , "davem@davemloft.net" , "edumazet@google.com" , "kuba@kernel.org" , "pabeni@redhat.com" , "simon.horman@corigine.com" , "netdev@vger.kernel.org" , dl-linux-imx , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH V2 net-next] net: fec: add CBS offload support Message-ID: References: <20230213092912.2314029-1-wei.fang@nxp.com> <8b25bd1f-4265-33ea-bdb9-bc700eff0b0e@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > I have tested the pure software CBS today. And below are the test steps and results. > Link speed 100Mbps. > Queue 0: Non-CBS queue, 100Mbps traffic. > Queue 1: CBS queue, 7Mbps bandwidth and 8Mbps traffic. > Queue 2: CBS queue, 5Mbps bandwidth and 6Mbps traffic. > Results: queue 0 egress rate is 86Mbps, queue 1 egress rate is 6Mbps, and queue 2 > egress rate is 4Mbps. > Then change the link speed to 10Mbps, queue 0 egress rate is 4Mbps, queue 1 egress > rate is 4Mbps, and queue 2 egress rate is 3Mbps. > > Beside the test results, I also checked the CBS codes. Unlike hardware implementation, > the pure software method is more flexible, it has four parameters: idleslope, sendslope, > locredit and hicredit. And it can detect the change of link speed and do some adjust. > However, for hardware we only use the idleslope parameter. It's hard for us to make > the hardware behave as the pure software when the link speed changes. > So for the question: Should the hardware just give up and go back to default behaviour, > or should it continue to do some CBS? If you give up on hardware CBS, does the software version take over? The idea of hardware offload is that the user should not care, nor really notice. You want the software and hardware behaviour to be similar. > I think that we can refer to the behaviors of stmmac and enetc drivers, just keep the > bandwidth ratio constant when the link rate changes. In addition, the link speed change > is a corner case, there is no need to spend any more effort to discuss this matter. It is a corner case, but it is an important one. You need it to do something sensible. Giving up all together is not sensible. Falling back to software CBS would be sensible, or supporting something similar to the software CBS. Andrew