Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 20 Apr 2023 16:40:59 +0200
From:   Simon Horman <simon.horman@corigine.com>
To:     Vladimir Oltean <vladimir.oltean@nxp.com>
Cc:     netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
        Michal Kubecek <mkubecek@suse.cz>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Claudiu Manoil <claudiu.manoil@nxp.com>,
        Xiaoliang Yang <xiaoliang.yang_1@nxp.com>,
        Petr Machata <petrm@nvidia.com>,
        Danielle Ratson <danieller@nvidia.com>,
        Pranavi Somisetty <pranavi.somisetty@amd.com>,
        Harini Katakam <harini.katakam@amd.com>,
        Vinicius Costa Gomes <vinicius.gomes@intel.com>,
        Kurt Kanzenbach <kurt@linutronix.de>,
        Gerhard Engleder <gerhard@engleder-embedded.com>,
        Ferenc Fejes <ferenc.fejes@ericsson.com>,
        Aaron Conole <aconole@redhat.com>,
        linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 net-next 2/9] net: enetc: report mm tx-active based on
 tx-enabled and verify-status
Message-ID: <ZEFO+42Qy2sIxwpI@corigine.com>
References: <20230418111459.811553-1-vladimir.oltean@nxp.com>
 <20230418111459.811553-3-vladimir.oltean@nxp.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230418111459.811553-3-vladimir.oltean@nxp.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?pkNHUi9ySC/2lcW8ajP9gB1t4vnjb/o5id09Q7bUDJRp2ybI+ueQHOD2A9Ia?=
 =?us-ascii?Q?ATTrdID/4th3+r5e7rxT1b26r0Idjnj49M3NiVcxMLInt9h/zjvz65UodTwm?=
 =?us-ascii?Q?6Sbp1yWJyL/13gZI8m09IgLXR4txFI3vSnbQtqe1oLwEb3ubxD4FyGV6E4AP?=
 =?us-ascii?Q?+Y5uL8FOsHagH8HPplJ10U8v1cxF0y1o/nmxDbjDx92zyu4K7CjRAH6+8HHC?=
 =?us-ascii?Q?tqx6V7cbApp2lyrnYS+cL/EPgZSKhjCAezvKaVmuq+hbWYKFBj6Na33ciIVR?=
 =?us-ascii?Q?0sZT8zbGMwqu9U4vj5ClT24p2ER7B6wynBM+zYZH33ZoliMvvHli4eslP21B?=
 =?us-ascii?Q?9DdZPoeR101PDCkZZn4A9vpyDlse8/bHRepvvC3jeNMD2xwIJi0JsCNkqxam?=
 =?us-ascii?Q?hXR3tadrEsRyp3wugFHV/I5fF2QRKaAi85kAmRGBAWw2hDXZN/VqAZ85ChB/?=
 =?us-ascii?Q?g2rwSaQodhGUvtiXv9Qdt6TYgD8s1wi0Sx8hNFKmLI3dehbKAom839R1t6CB?=
 =?us-ascii?Q?Yk1BZ34Cvzp5UNsa2f+Htx+Rhjkh5/y8UrCZ9dzQ8fpagGVRlui/Oa0fyIhc?=
 =?us-ascii?Q?JBh55HYr9KzjT2R3Clj7yUsBMFvuHHLnGL3R8FnedeXlkDNWVeZKACmW90jY?=
 =?us-ascii?Q?vsWelEg09vaS4Y/5Vruyzf6T8GkX3a1nyjdAsOn55CEKCCfloTHwiQ8+KX43?=
 =?us-ascii?Q?164UWTipy7OVLF+O3Ou8CpxD20LJJkWWYLpNMa+esooK7n4/nPMv+OhhC5Pr?=
 =?us-ascii?Q?jMbNS8j3b3ZbjlADblNoul6um48j3LtOAx0hZSuA92pm+8JHuv5VY6qvTlzR?=
 =?us-ascii?Q?GLH4C9JD8t56vf7+r7JntDpmZY8gvogkuEfGXuqONu481UbqYiHR/7Dxuqrz?=
 =?us-ascii?Q?xScKF+ErAtSEO9VAI5U21fVC66EG12oDtuImFJhREV1au6TPol9hwtfhdUJ3?=
 =?us-ascii?Q?vZkBiFkCxKHrSSFOdfoWoX04i8tdiLrloJG/3csiZ/hJx6XZbTq5aV+kHLFY?=
 =?us-ascii?Q?NbYS8xZIpdVN0f1p/5wD05WLR6/cRrCjLZBMDVOOd3KiLxoTaazx7IvYokL7?=
 =?us-ascii?Q?ayorqT2cdq3LTGLcnGIOl0A9ZYKSCr9wHYjSsxkBZKPfL38hu5q6pE/D2od8?=
 =?us-ascii?Q?Qmru5OeYqAGc8zdp0dRQhsC4a4idpHXd7TCXDB+2wpKXqlyQyGNDPZk5+Wl1?=
 =?us-ascii?Q?5/oaiMDoNl4h4DCDNCtbrgrQaQIFp2hmJTrrsXg1wTvV2Ib+NWLmb01hx4xu?=
 =?us-ascii?Q?X2cCEcMmMBGv8o+yaICIoqJwtAWgGQL11MgclJlZIFuvT2vfzcTKgJYs7i4Y?=
 =?us-ascii?Q?HtG+JVJZD2VjVSm3b/8JjmjS5OoPfHfcNvcx4Z+wsofWZscSEfIEkw1i1Ukq?=
 =?us-ascii?Q?iVXqOkcmML7hCFZALVn+9cPsD5kHP+76m/C3/ZYeuT1yR+k7IsIfwvdAeu3d?=
 =?us-ascii?Q?IQiVCK0xwCxHNGh+jpOiN9itVb24iI5yI5y4mJFXNgPWgnoGFexgs6iEihTh?=
 =?us-ascii?Q?nzbmDQ8HpNe38lWiqp3VNTgpKi5dQ5YZFv3+LHRfoJ3hSPLD6Jh08CI5f9yv?=
 =?us-ascii?Q?2GA1/idnUYj0aVWT7LTBUfTkneVqKxejTn+4Y+TyHSne/nAOO3fpi4zXVNNl?=
 =?us-ascii?Q?2uKvxiW84aVaLX96r9P+YYUIEb1GGb1VLwjG7GXJKiMY2rGDEmM67/YBIcY4?=
 =?us-ascii?Q?79/GsA=3D=3D?=
X-OriginatorOrg: corigine.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fd9da178-8ba7-4573-1698-08db41ad46ea
X-MS-Exchange-CrossTenant-AuthSource: PH0PR13MB4842.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2023 14:41:08.3378
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: fe128f2c-073b-4c20-818e-7246a585940c
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: uRjFdk922btCDVHofvRxPZgUfd7+G+9NNGFzhDDI6moDjaLbYfPzzKfGI7EbZmhVXc1Jqikgn18pznUVRr8jUxbJw19M5Qc6tatIiedeXlM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR13MB5792
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,
        T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 18, 2023 at 02:14:52PM +0300, Vladimir Oltean wrote:
> The MMCSR register contains 2 fields with overlapping meaning:
> 
> - LPA (Local preemption active):
> This read-only status bit indicates whether preemption is active for
> this port. This bit will be set if preemption is both enabled and has
> completed the verification process.
> - TXSTS (Merge status):
> This read-only status field provides the state of the MAC Merge sublayer
> transmit status as defined in IEEE Std 802.3-2018 Clause 99.
> 00 Transmit preemption is inactive
> 01 Transmit preemption is active
> 10 Reserved
> 11 Reserved
> 
> However none of these 2 fields offer reliable reporting to software.
> 
> When connecting ENETC to a link partner which is not capable of Frame
> Preemption, the expectation is that ENETC's verification should fail
> (VSTS=4) and its MM TX direction should be inactive (LPA=0, TXSTS=00)
> even though the MM TX is enabled (ME=1). But surprise, the LPA bit of
> MMCSR stays set even if VSTS=4 and ME=1.
> 
> OTOH, the TXSTS field has the opposite problem. I cannot get its value
> to change from 0, even when connecting to a link partner capable of
> frame preemption, which does respond to its verification frames (ME=1
> and VSTS=3, "SUCCEEDED").
> 
> The only option with such buggy hardware seems to be to reimplement the
> formula for calculating tx-active in software, which is for tx-enabled
> to be true, and for the verify-status to be either SUCCEEDED, or
> DISABLED.
> 
> Without reliable tx-active reporting, we have no good indication when
> to commit the preemptible traffic classes to hardware, which makes it
> possible (but not desirable) to send preemptible traffic to a link
> partner incapable of receiving it. However, currently we do not have the
> logic to wait for TX to be active yet, so the impact is limited.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>

Reviewed-by: Simon Horman <simon.horman@corigine.com>