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.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, 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 337B1C47096 for ; Thu, 3 Jun 2021 12:34:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1509B6136E for ; Thu, 3 Jun 2021 12:34:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230324AbhFCMfn (ORCPT ); Thu, 3 Jun 2021 08:35:43 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:58679 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230163AbhFCMfj (ORCPT ); Thu, 3 Jun 2021 08:35:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622723633; 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=x5NtUVUE03a6WWucGBbuNsprX88T5ZoyDg605ZeHb7o=; b=FJnSwOaEsWORYwiO7ziPUOjzuURd/boJplA3FUJbRNhj9Em9Cj31Ni5ienT9oPv2H4vvjN hu02AK5xBJQO/CJUkqhXFpkJZhnYPldXA19qzNdtBwr9PVRQvDMTLcboA9ypcU6pKSD2/4 kBoWRG/jr56WifjHpjxJX7RsqvxNpWM= Received: from mail-io1-f72.google.com (mail-io1-f72.google.com [209.85.166.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-103-oDu3vfoHPdqk_NHB3d2vpg-1; Thu, 03 Jun 2021 08:33:52 -0400 X-MC-Unique: oDu3vfoHPdqk_NHB3d2vpg-1 Received: by mail-io1-f72.google.com with SMTP id s14-20020a5eaa0e0000b02904abce57cb24so824041ioe.21 for ; Thu, 03 Jun 2021 05:33:51 -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:content-transfer-encoding; bh=x5NtUVUE03a6WWucGBbuNsprX88T5ZoyDg605ZeHb7o=; b=FL3KoZFy98duY9rMRVCjWH5baycfZGbd83J+6Ddsawlt4Srrf2DlscqkWZ0XWD/Aj2 Vgryay3hF3y727wRFwTyt04kScrNMmwFfLMe1Oa6PJffgcR/uQ8PKGgVn2mRucecuPKs f5paXgRJ/JM1RjHuoXMLifPFKxqpRrhiPjvBh97piFROcU93kjo9nJnLRsTyC/8704JH JIo0ZVhiXzwObWaNqtsjhj1MxOaG9PiseCytcBnVRgdx8nyBaTDiWZuoGUsi8QvXJMNf D8ujetoxUlOVLglKG4HEnv9IibVxsjfPidb5DU6ru4KWx0oTSKDFpW7pDl/uHnViFSeK YU3A== X-Gm-Message-State: AOAM533wfu2UF+recoKS7hirFDu+80j09C6APf1ZwSGE+ypn1vsLypmP 9J3w8NEDNCdTxfurXR9Gc6JQMEnsFamrfiUhpZeSt9DjbiNG1Yin1fxUFJk+VTmeAjjdHQ99bDe C/6Kzu7PcLRvEFeEsHN327jGDDuce/5Tinilgng5t X-Received: by 2002:a05:6638:bc2:: with SMTP id g2mr6114851jad.119.1622723631212; Thu, 03 Jun 2021 05:33:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyWqoeJcY+vQe09Awc00pitHbN7SSsf+0/mIxZuSe1sHdQ1t/FIC4tKljBzzk3bcknzFuKn71W8Wx/ZtUgy+wA= X-Received: by 2002:a05:6638:bc2:: with SMTP id g2mr6114800jad.119.1622723630584; Thu, 03 Jun 2021 05:33:50 -0700 (PDT) MIME-Version: 1.0 References: <20210603063430.6613-1-ihuguet@redhat.com> <20210603074419.2930-1-hdanton@sina.com> In-Reply-To: <20210603074419.2930-1-hdanton@sina.com> From: =?UTF-8?B?w43DsWlnbyBIdWd1ZXQ=?= Date: Thu, 3 Jun 2021 14:33:39 +0200 Message-ID: Subject: Re: [PATCH 1/2] net:cxgb3: replace tasklets with works To: Hillf Danton Cc: rajur@chelsio.com, "David S. Miller" , Jakub Kicinski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Ivan Vecera Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 3, 2021 at 9:47 AM Hillf Danton wrote: > > On Thu, 3 Jun 2021 08:34:29 +0200 Inigo Huguet wrote: > > > > Moreover, given that probably the ring is not empty yet, so the > > DMA still has work to do, we don't need to be so fast to justify > > using tasklets/softirq instead of running in a thread. > > [...] > > > - tasklet_kill(&qs->txq[TXQ_OFLD].qresume_tsk); > > - tasklet_kill(&qs->txq[TXQ_CTRL].qresume_tsk); > > + cancel_work_sync(&qs->txq[TXQ_OFLD].qresume_task); > > + cancel_work_sync(&qs->txq[TXQ_OFLD].qresume_task); > > This is the last minute mark that figures are needed to support your > reasoning above. OFLD queue has length=3D1024, and CTRL queue length=3D256. If a queue is so full that the next packet doesn't fit, driver "stop" that queue. That means that it adds the new outcoming packets to a list of packets which are pending from being enqueued. Packets which were already in the queue keep being processed by the DMA. When the queue has half or more of free space, pending packets are moved from the "pending" list to the queue. If the list got full in the first place, it was because the NIC was processing the packets slower than the CPU was trying to send them. Given that, it is reasonable to think that there is enough time to enqueue the pending packets before the DMA and the NIC are able to process the other half of data still in the queue. If for some reason the situation has changed in the meanwhile, and now the NIC is capable of sending the packets REALLY fast, and the queue gets empty before the qresume_task is run, it will be a small delay only once, not many times, so it is not a big problem. But honestly, I don't know if this situation can really happen in practice. In my opinion there are no drawbacks moving these tasks to threads, and in exchange we avoid increasing latencies in softirq context. Consider that there might be a high amount of packets pending of being enqueued, and in these "resume" tasks pending packets keep being enqueued until there are no more of them, or until the queue gets full again. The "resume" task might run for quite a long time. cancel_work_sync is only called when the interface is set to down state or the module removed. -- =C3=8D=C3=B1igo Huguet