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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DE1CBC6FA83 for ; Tue, 6 Sep 2022 07:17:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238292AbiIFHRq (ORCPT ); Tue, 6 Sep 2022 03:17:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60584 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238836AbiIFHRm (ORCPT ); Tue, 6 Sep 2022 03:17:42 -0400 Received: from mail.3ffe.de (0001.3ffe.de [159.69.201.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40BBE73935; Tue, 6 Sep 2022 00:17:41 -0700 (PDT) Received: from 3ffe.de (0001.3ffe.de [IPv6:2a01:4f8:c0c:9d57::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.3ffe.de (Postfix) with ESMTPSA id 8794E21BD; Tue, 6 Sep 2022 09:17:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2022082101; t=1662448659; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Qxi49WzANBodoTQOX0E/K8f/DX4qR1X+vWMmaXpTEi0=; b=meVG/NVLfkJRQq1uQnr1QrnzD86804WP6rLDZ4fMa74eMzJRJ06DuH2PpAeYygx6Q0yVmI CKxYu2kWDrIH7e5gBxduRNf0iG3RAQ/QV8226tNmvaCHkSj9YzB4ZCRlLWBfZfKjlQTR+F /hEGP/tq0pYx88MrddxkP9B1G6W82MBFEuSFNxflm2i4E0qRiG6PAmm6ZAx3vPM82q3LFN MZ0rHiuraa/yULLl/UrQtGZvoVj1DSpb+2BGFwu3Ftmu823xOZu51ZKHMNUGXbSlbOORKW 6fXPcV+4bmlYLw/pf4d+0295AYasFcyNwKeymFV1krtZDiB2m74YBPiDpCgLKg== MIME-Version: 1.0 Date: Tue, 06 Sep 2022 09:17:39 +0200 From: Michael Walle To: Vladimir Oltean Cc: netdev@vger.kernel.org, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Xiaoliang Yang , Claudiu Manoil , Alexandre Belloni , UNGLinuxDriver@microchip.com, Andrew Lunn , Vivien Didelot , Florian Fainelli , Vinicius Costa Gomes , Maxim Kochetkov , Colin Foster , Richie Pearn , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 net 1/3] net: dsa: felix: tc-taprio intervals smaller than MTU should send at least one packet In-Reply-To: <20220906001134.ikooyzebb4pmgzib@skbuf> References: <20220905170125.1269498-1-vladimir.oltean@nxp.com> <20220905170125.1269498-2-vladimir.oltean@nxp.com> <20220906001134.ikooyzebb4pmgzib@skbuf> User-Agent: Roundcube Webmail/1.4.13 Message-ID: <0c7c5fecc853ce161236f66c517b7474@walle.cc> X-Sender: michael@walle.cc Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 2022-09-06 02:11, schrieb Vladimir Oltean: > On Tue, Sep 06, 2022 at 12:53:20AM +0200, Michael Walle wrote: >> I haven't looked at the overall code, but the solution described >> above sounds good. >> >> FWIW, I don't think such a schedule, where exactly one frame >> can be sent, is very likely in the wild though. Imagine a piece >> of software is generating one frame per cycle. It might happen >> that during one (hardware) cycle there is no frame ready (because >> it is software and it jitters), but then in the next cycle, there >> are now two frames ready. In that case you'll always lag one frame >> behind and you'll never recover from it. >> >> Either I'd make sure I can send at two frames in one cycle, or >> my software would only send a frame every other cycle. > > A 10 us interval is a 10 us interval, it shouldn't matter if you slice > it up as one 1250B frame, or two 500B frames, or four 200B frames, etc. > Except with the Microchip hardware implementation, it does. In v1, we > were slicing the 10 us interval in half for useful traffic and half for > the guard band. So we could fit more small packets in 5 us. In v2, at > your proposal, we are slicing it in 33 ns for the useful traffic, and > 10 us - 33 ns for the guard band. This indeed allows for a single > packet, be it big or small. It's how the hardware works; without any > other input data point, a slicing point needs to be put somewhere. > Somehow it's just as arbitrary in v2 as where it was in v1, just > optimized for a different metric which you're now saying is less > practical. I actually checked the code before writing and saw that one could change the guard band by setting the MTU of the interface. I though, "ah ok, then there is no issue". After sleeping, I noticed that you'd restrict the size of all the frames on the interface. Doh ;) -michael > By the way, I was a fool in last year's discussion on guard bands for > saying that there isn't any way for the user to control per-tc MTU. > IEEE 802.1Qbv, later standardized as IEEE 802.1Q clause 8.6.8.4 > Enhancements for scheduled traffic, does contain a queueMaxSDUTable > structure with queueMaxSDU elements. I guess I have no choice except to > add this to the tc-taprio UAPI in a net-next patch, because as I've > explained above, even though I've solved the port hanging issue, this > hardware needs more fine tuning to obtain a differentiation between > many > small packets vs few large packets per interval.