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 78B65C3DA64 for ; Thu, 1 Aug 2024 23:17:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=vRHY8LMAMsDzYIYRh2DEhqf/+ZSkBDumcnyt9s3s3SU=; b=2eMdfDqXWi5YhHEHaWBKq/8TE+ /hosi1XpzFCM2ykpWqmC8F+hXxPnT5BrJNdb04IhC+h/p/HL5FPu7c3zZmoC9J6we5q9nioVhSJ8V 9emy37YmnAcUqiKKt00HjbhCzWaGjj1cNbwnwkAsaoPn2N1g6qHrdKEq3iR/niHYtBz/19evBC/C+ 9egGbOrRYzbkT7ykfH+uiF5hYqlb/KfrD7im20JoSCs+VbCoPWhlQ5fx3Wu1MpkH8eugu2VPCuVEt OkllkKiiiZ7kYUSqrYw0OmC5rzMAdHya/7qQk3OvzEa98pH6BTwxCCS/aSodoY/4lgL7+gQSIcQBi ESaxhqNA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sZf2f-000000070pQ-1gza; Thu, 01 Aug 2024 23:17:05 +0000 Received: from mail-ej1-x631.google.com ([2a00:1450:4864:20::631]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sZf27-000000070et-0zu5 for linux-arm-kernel@lists.infradead.org; Thu, 01 Aug 2024 23:16:33 +0000 Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a7a9cf7d3f3so925718466b.1 for ; Thu, 01 Aug 2024 16:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722554189; x=1723158989; darn=lists.infradead.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=vRHY8LMAMsDzYIYRh2DEhqf/+ZSkBDumcnyt9s3s3SU=; b=D1v73cZDzK39tfyU2W5pmfHHOw1HHPIvpj/lHV6J5pKsNPh7/JKRq8B9NF9fckeuHr Wvup66WeMsdCoEJuQu5KGpBZv/0BkRvtj4YwWlEa5o4CatI8GqOwuQv90xt98OUdLFyL f43Qsrsrt+0QyiCj/rkcmbUCk5KVouIz2vCAvo90Omzg97DSZ+RKqca0jIAHDUhWquNk Wd4o8zC2XYUOtDMrLXtd7sw1SKacwlRF1MEVIUSoRJejLu/9OF/2g2+W+ykhM0mAIwah 3aftsbg8jNBP7MuECs+ChVFCUoOk/pJoLUfr8vP0yC3vK8CqJ92rYrxdXrF3e8U3k9Jc WHdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722554189; x=1723158989; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vRHY8LMAMsDzYIYRh2DEhqf/+ZSkBDumcnyt9s3s3SU=; b=LvE+lKeZvgOCid5TSJi39XiNJ7Z1ItiaJkV+QIkqPtyAMTIkDhcACL93N7HeS3mfpS UivZb6idpxWandSAUe1UgG33CJ1IE4MSeHcXnLXSowFK6aJ1IKA3Lsk/nWPJeYMMfhzp 739GoZRNYPRmqMpBgEvZaCVhQuuF9K5vPwn9Czyo9Xyqyd8fvkuP8OT9DF93tEjgDppm 7pF9ZVNQgbcDm7EqJYb+w9DIYo3ooUJZbGss9jTOiDeL9KsCW9s73hiDKenxL+rHgejM RhwDpnfhjkdVd9rpOU8eYl46kkuZhSI6gZvHvaGT8LHBFbh0RBAwnbUN/TnG3e0AH7DE ohrg== X-Forwarded-Encrypted: i=1; AJvYcCUiEIMviBU6c21jXD1bSbE8GfQ9juN3o/UJw749h8wVW6TMn+cUQjd16vFW/vnxWPpgAE5VvJWQ91NvPuvxoNaMTeaPSTV1r8wmPpZd20oYhzdvDV4= X-Gm-Message-State: AOJu0YzAZvA9LIitfHlPJ5vScnX0VvhOZ8L74tX911Xnpqls4j5Y5ikD kwlKC4Zi/MJYMZx9cIAuoGcn2bI9ha2TLSs6OPRmR/ItdMA8BUY3 X-Google-Smtp-Source: AGHT+IEsxgfvGijlQDD+0yGHl9Bv4Sl5rFZvFBX00pRtsgyK5toVPnhYX03gaMnFF/r02MjdVSWnNg== X-Received: by 2002:a17:907:3f28:b0:a7a:acae:3415 with SMTP id a640c23a62f3a-a7dc4db4b08mr146394566b.10.1722554188713; Thu, 01 Aug 2024 16:16:28 -0700 (PDT) Received: from skbuf ([188.25.135.70]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7dc9bcada0sm30237866b.31.2024.08.01.16.16.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Aug 2024 16:16:27 -0700 (PDT) Date: Fri, 2 Aug 2024 02:16:25 +0300 From: Vladimir Oltean To: Furong Xu <0x1207@gmail.com> Cc: Andrew Lunn , "David S. Miller" , Alexandre Torgue , Jose Abreu , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Maxime Coquelin , Joao Pinto , netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, xfr@outlook.com, rock.xu@nio.com Subject: Re: [PATCH net-next v1 3/5] net: stmmac: support fp parameter of tc-taprio Message-ID: <20240801231625.uqa4gq7vokp63dfp@skbuf> References: <4603a4f68616ce41aca97bac2f55e5d51c865f53.1722421644.git.0x1207@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4603a4f68616ce41aca97bac2f55e5d51c865f53.1722421644.git.0x1207@gmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240801_161631_306094_FEDA01D0 X-CRM114-Status: GOOD ( 24.42 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jul 31, 2024 at 06:43:14PM +0800, Furong Xu wrote: > tc-taprio can select whether traffic classes are express or preemptible. > > After some traffic tests, MAC merge layer statistics are all good. > > Local device: > ethtool --include-statistics --json --show-mm eth1 > [ { > "ifname": "eth1", > "pmac-enabled": true, > "tx-enabled": true, > "tx-active": true, > "tx-min-frag-size": 60, > "rx-min-frag-size": 60, > "verify-enabled": true, > "verify-time": 100, > "max-verify-time": 128, > "verify-status": "SUCCEEDED", > "statistics": { > "MACMergeFrameAssErrorCount": 0, > "MACMergeFrameSmdErrorCount": 0, > "MACMergeFrameAssOkCount": 0, > "MACMergeFragCountRx": 0, > "MACMergeFragCountTx": 1398, > "MACMergeHoldCount": 15783 > } > } ] > > Remote device: > ethtool --include-statistics --json --show-mm eth1 > [ { > "ifname": "eth1", > "pmac-enabled": true, > "tx-enabled": true, > "tx-active": true, > "tx-min-frag-size": 60, > "rx-min-frag-size": 60, > "verify-enabled": true, > "verify-time": 100, > "max-verify-time": 128, > "verify-status": "SUCCEEDED", > "statistics": { > "MACMergeFrameAssErrorCount": 0, > "MACMergeFrameSmdErrorCount": 0, > "MACMergeFrameAssOkCount": 1388, > "MACMergeFragCountRx": 1398, > "MACMergeFragCountTx": 0, > "MACMergeHoldCount": 0 > } > } ] > > Tested on DWMAC CORE 5.10a > > Signed-off-by: Furong Xu <0x1207@gmail.com> > --- > .../net/ethernet/stmicro/stmmac/stmmac_tc.c | 34 ++----------------- > 1 file changed, 3 insertions(+), 31 deletions(-) > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c > index 494fe2f68300..eeb5eb453b98 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c > @@ -943,7 +943,6 @@ static int tc_taprio_configure(struct stmmac_priv *priv, > u32 size, wid = priv->dma_cap.estwid, dep = priv->dma_cap.estdep; > struct timespec64 time, current_time, qopt_time; > ktime_t current_time_ns; > - bool fpe = false; > int i, ret = 0; > u64 ctr; > > @@ -1028,16 +1027,6 @@ static int tc_taprio_configure(struct stmmac_priv *priv, > > switch (qopt->entries[i].command) { > case TC_TAPRIO_CMD_SET_GATES: > - if (fpe) > - return -EINVAL; > - break; > - case TC_TAPRIO_CMD_SET_AND_HOLD: > - gates |= BIT(0); > - fpe = true; > - break; > - case TC_TAPRIO_CMD_SET_AND_RELEASE: > - gates &= ~BIT(0); > - fpe = true; I don't think these can go. In the DWMAC5 manual, I see: "To enable the support of hold and release operations, the format of the GCL is slightly changed while configuring and enabling the FPE. The first Queue (Q0) is always programmed to carry preemption traffic and therefore it is always Open. The bit corresponding to Q0 is renamed as Release/Hold MAC control. The TX Queues whose packets are preemptable are indicated by setting the PEC field of the MTL_FPE_CTRL_STS register. The GCL bit of the corresponding Queue are ignored and considered as always "Open". So, even if the software writes a "0" ("C"), it is ignored for such queues." It's relatively clear to me that this is what the "gates" variable is doing here - it's modulating when preemptible traffic begins to be "held", and when it is "released". Now, the "fpe" variable - that can definitely go. > break; > default: > return -EOPNOTSUPP; Also, this is more general advice. If TC_TAPRIO_CMD_SET_AND_HOLD and TC_TAPRIO_CMD_SET_AND_RELEASE used to work as UAPI input into this driver, you don't want to break that now by letting those fall into the default -EOPNOTSUPP case. What worked must continue to work... somehow. > @@ -1068,16 +1057,11 @@ static int tc_taprio_configure(struct stmmac_priv *priv, > > tc_taprio_map_maxsdu_txq(priv, qopt); > > - if (fpe && !priv->dma_cap.fpesel) { > + if (qopt->mqprio.preemptible_tcs && !priv->dma_cap.fpesel) { > mutex_unlock(&priv->est_lock); > return -EOPNOTSUPP; > } > > - /* Actual FPE register configuration will be done after FPE handshake > - * is success. > - */ > - priv->plat->fpe_cfg->enable = fpe; > - > ret = stmmac_est_configure(priv, priv, priv->est, > priv->plat->clk_ptp_rate); > mutex_unlock(&priv->est_lock);