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=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 33B55C48BD3 for ; Wed, 26 Jun 2019 20:24:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0F3AF2085A for ; Wed, 26 Jun 2019 20:24:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726373AbfFZUYs (ORCPT ); Wed, 26 Jun 2019 16:24:48 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:60473 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726341AbfFZUYr (ORCPT ); Wed, 26 Jun 2019 16:24:47 -0400 Received: from mail-wr1-f70.google.com ([209.85.221.70]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1hgETF-00018o-97 for netdev@vger.kernel.org; Wed, 26 Jun 2019 20:24:45 +0000 Received: by mail-wr1-f70.google.com with SMTP id v7so35661wrt.6 for ; Wed, 26 Jun 2019 13:24:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q8e0cQcjtNecIM29dBcL0Lfdw9lK8pi0Bnd8zPrOvpQ=; b=aChIm/1TCbUYMtwz5P8VHoY5463eEwLtS3/KSHDAfs5YVeyknfr7hFsH1NorrnathR YtGsb+K6IEfc0arkjkN8RnRFvBuPAm01SpIyy43TAacRVvHlkEEAUZRaSf4Rd/HBqMaq WYC7zg7GzppungY/agczHuNs/KRbY5suXavPf0mc/fk/gfLE+uN9446xlm8hu/EvKh+p czsOUsbjJe8/ys7zysWOPIA0rselkYxWG+jXCe3RgsHYBauV2+ViUD3GwuhEzFT5PI5J N3LZ94J7tFepML0lhTcn/nqgUnJPzhyX/gX2gNtt6SWxz8L8pmOLa+0wQ+pisZoQhzwY jDJQ== X-Gm-Message-State: APjAAAXiiB7ji5gWZlrZ9q6dh9ESacBc6Rzu+wS+uzVxxDi4OIl8FQFG A4+CHmvw3BzZDFnctqLRRasUMTKC3JJLd0cN3TzaERyIQoNfWf6xUtbUcI1j1eg9Ex98yig/yyh uSH1d492VRwv3bmXyji+CtB8UOsehJE6Tj5tr0iyAMIA1CWgaFw== X-Received: by 2002:a5d:61cd:: with SMTP id q13mr5067709wrv.114.1561580685058; Wed, 26 Jun 2019 13:24:45 -0700 (PDT) X-Google-Smtp-Source: APXvYqyHEhQq4Nh6haEIn99u4e89QGD/+sHLbj6xDuJPIADSkG0N7U8A+xyjKhWG+gkA3vLgrOTnX5ldr8jUpKvREIA= X-Received: by 2002:a5d:61cd:: with SMTP id q13mr5067702wrv.114.1561580684914; Wed, 26 Jun 2019 13:24:44 -0700 (PDT) MIME-Version: 1.0 References: <20190624222356.17037-1-gpiccoli@canonical.com> In-Reply-To: From: Guilherme Piccoli Date: Wed, 26 Jun 2019 17:24:08 -0300 Message-ID: Subject: Re: [EXT] [PATCH V2] bnx2x: Prevent ptp_task to be rescheduled indefinitely To: Sudarsana Reddy Kalluru Cc: "jay.vosburgh@canonical.com" , GR-everest-linux-l2 , "netdev@vger.kernel.org" , Ariel Elior Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Jun 26, 2019 at 5:25 AM Sudarsana Reddy Kalluru wrote: > > Sudarsana, let me ask you something: why does the register is reading value > > 0x0 always in the TX timestamp routine if the RX filter is set to None? This is > > the main cause of the thread reschedule thing. > > The register value of zero indicates there is no pending Tx timestamp to be read by the driver. > FW writes/latches the Tx timestamp for PTP event packet in this register. And it does the latching only if the register is free. > In this case user/app look to be requesting the Timestamp (via skb->tx_flags) for non-ptp Tx packet. In the Tx path, driver schedules a thread for reading the Tx timestamp, > bnx2x_start_xmit() > { > if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)) > schedule_work(&bp->ptp_task); > } > FW seem to be not timestamping the packet at all and driver is indefinitely waiting for it. > Thanks Sudarsana! I've tried to implement the qede-like approach again, with the 2s timeout before bailing-out the thread reschedule. This time, I've remove _all_log messages, including the DP() ones... Unfortunately kthread is still consuming 100% of CPU, which makes sense, since it reschedules itself the most times it can in this 2s window...I think we really should have small pauses before retrying to read the registers. I've worked a V3, implementing 1ms-starting pauses, which worked well: https://marc.info/?l=linux-netdev&m=156158032618932 I hope this way we don't harm the PTP applications, nor introduce delays in the FW wait-queue, and at same time we can fix the indefinitely reschedule in bnx2x. Thanks again for your support, Guilherme