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 X-Spam-Level: X-Spam-Status: No, score=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 49965C433B4 for ; Wed, 19 May 2021 20:49:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 20DD96135A for ; Wed, 19 May 2021 20:49:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229505AbhESUuX (ORCPT ); Wed, 19 May 2021 16:50:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:58600 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229379AbhESUuV (ORCPT ); Wed, 19 May 2021 16:50:21 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 8B6BD6135A; Wed, 19 May 2021 20:49:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621457341; bh=x3LMoDLLoJzEGziXgwlgGLRIC/je0Pnn+GYwKgGdf8g=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=rLKjIkbZ3GBu4wFd794rGKDP9wiNRrcJ+GQcX2ieL+2eAGPzzVBZfN/5dl0ViAVL2 6YNZFuupEFRFpJujodL/7nT9wvhgbj601hWiNGpKeUxFrem06DxsB1rCsle9/7bcFw hAg8CBUVHhY1niCX1GX0Q2Qf64oMmSBUpvJhL36S9CTjMah6QeFR7pAWaa3Oz6cyFo XqjSpNZKvFB0YX++ac+xKuPH29SV+OdO/oRd7DgnQhUYWWZE8aqUMBowl0sekYUZ64 airBZogcF6JjKZgVDoM91UIPU1SC+sAiXqtFD+MxLoiFWBE6/jGmi42+QVBIcJXmGB yXo9AlRoDkVWg== Message-ID: Subject: Re: [PATCH net-next] mlx5: count all link events From: Saeed Mahameed To: Jakub Kicinski Cc: davem@davemloft.net, netdev@vger.kernel.org Date: Wed, 19 May 2021 13:49:00 -0700 In-Reply-To: <20210519171825.600110-1-kuba@kernel.org> References: <20210519171825.600110-1-kuba@kernel.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, 2021-05-19 at 10:18 -0700, Jakub Kicinski wrote: > mlx5 devices were observed generating MLX5_PORT_CHANGE_SUBTYPE_ACTIVE > events without an intervening MLX5_PORT_CHANGE_SUBTYPE_DOWN. This > breaks link flap detection based on Linux carrier state transition > count as netif_carrier_on() does nothing if carrier is already on. > Make sure we count such events. > Can you share more on the actual scenario that has happened ? in mlx5 i know of situations where fw might generate such events, just as FYI for virtual ports (vports) on some configuration changes. another explanation is that in the driver we explicitly query the link state and we never take the event value, so it could have been that the link flapped so fast we missed the intermediate state. According to HW spec for some reason we should always query and not rely on the event. If software retrieves this indication (port state change event), this signifies that the state has been changed and a QUERY_VPORT_STATE command should be performed to get the new state. > netif_carrier_event() increments the counters and fires the linkwatch > events. The latter is not necessary for the use case but seems like > the right thing to do. >