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.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 ED333C43381 for ; Wed, 27 Mar 2019 17:14:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BAF78206C0 for ; Wed, 27 Mar 2019 17:14:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fTCr6OeB" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727707AbfC0RO3 (ORCPT ); Wed, 27 Mar 2019 13:14:29 -0400 Received: from mail-pf1-f196.google.com ([209.85.210.196]:43191 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727389AbfC0RO3 (ORCPT ); Wed, 27 Mar 2019 13:14:29 -0400 Received: by mail-pf1-f196.google.com with SMTP id c8so9995760pfd.10; Wed, 27 Mar 2019 10:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Yhssr0V72JvE91R2ZOFHzHcu4bU6qlsXKGFfct13GYk=; b=fTCr6OeBQssmPnV73r1PggOtz+bJ+WNykV6/nLM1JgFFSdmAJ6xUZ6bLobUBcEavVx E1E6Bx6jEzGLW/Do9fyKugW4KqFy532SdSX7FRnz+136gg8qtHyzoToDt40NDjx0FYJ7 QwVmetVRBlOQzM/U0KtIQ3CDkt184hBTLHeWw3+3y/Kb6fYuOMS2Qi+G9IFktoxtYiS/ rkhB2xgEfw3qhQFIISDdt5BPfedHcNEDK8AvtTCTz7IZ6FdzILPYcAsjlPYHB2f+sGHA i/seNlf9ELMtKqwXOYoKxXLfKZKG3zcBThtfe6YQUckIASqurtMWLXe5FaDYUhKJjM0S 3flA== 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=Yhssr0V72JvE91R2ZOFHzHcu4bU6qlsXKGFfct13GYk=; b=VsmSSzwvOJeYzIEgnV4vFedzsW7l6uJ/zbOduwbYIKCXfsvs/K2w1bLRFMfQ8M8f8/ 9WVrK4XqCEaMuq4ePtuEthVbHV7/ZVVEXqIA+z2f4fLk00YMz/Pb21+Q6NC1lZpryDcW otYU3OkHipxN3Zlt0QTgbO3BHMHMZExKupt9caL3o85jBN/I/PlSm54cwdG+kVHdogcg XbxBuCi7Kyp7UyzPlodNFtSXe21dvzv6j7tEdyL3d13n1da3ZYKfphuY/oY6FpvDV1dK T0xkBNNKrK6fvjjJEjAgjbYXsFsv25TbQW/Y3W1crr+wE8VqVlrLT5FQ04RnyHxGbOLa 5xuA== X-Gm-Message-State: APjAAAXvu5GEUajqtsgsp1LdlF7s0duEUWxqK19CbeWL9RrEqiDKkLM8 36CXGFN93Pdvra3JkG3Hhl9AuFudM6GiIoAlLno= X-Google-Smtp-Source: APXvYqzdWmcgqk0X6cEwZ3SNEY37mMVXpxauIoAZNY58VH8yvvdcc0Bl3AbMoMzJqo6jupi6ekTbQm7+ndIbICp5Hdw= X-Received: by 2002:a63:e845:: with SMTP id a5mr35080914pgk.246.1553706868724; Wed, 27 Mar 2019 10:14:28 -0700 (PDT) MIME-Version: 1.0 References: <20190327165632.10711-1-mkl@pengutronix.de> <20190327165632.10711-2-mkl@pengutronix.de> In-Reply-To: <20190327165632.10711-2-mkl@pengutronix.de> From: Cong Wang Date: Wed, 27 Mar 2019 10:14:17 -0700 Message-ID: Subject: Re: [PATCH 1/2] net: sch_generic: add flag IFF_FIFO_QUEUE to use pfifo_fast as default scheduler To: Marc Kleine-Budde Cc: Linux Kernel Network Developers , David Miller , linux-can@vger.kernel.org, kernel@pengutronix.de, Dave Taht , Jamal Hadi Salim , Jiri Pirko 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, Mar 27, 2019 at 9:56 AM Marc Kleine-Budde wrote: > > There is networking hardware that isn't based on Ethernet for layers 1 and 2. > > For example CAN. > > CAN is a multi-master serial bus standard for connecting Electronic Control > Units [ECUs] also known as nodes. A frame on the CAN bus carries up to 8 bytes > of payload. Frame corruption is detected by a CRC. However frame loss due to > corruption is possible, but a quite unusual phenomenon. > > While fq_codel works great for TCP/IP, it doesn't for CAN. There are a lot of > legacy protocols on top of CAN, which are not build with flow control or high > CAN frame drop rates in mind. > > When using fq_codel, as soon as the queue reaches a certain delay based length, > skbs from the head of the queue are silently dropped. Silently meaning that the > user space using a send() or similar syscall doesn't get an error. However > TCP's flow control algorithm will detect dropped packages and adjust the > bandwidth accordingly. > > When using fq_codel and sending raw frames over CAN, which is the common use > case, the user space thinks the package has been sent without problems, because > send() returned without an error. pfifo_fast will drop skbs, if the queue > length exceeds the maximum. But with this scheduler the skbs at the tail are > dropped, an error (-ENOBUFS) is propagated to user space. So that the user > space can slow down the package generation. > > On distributions, where fq_codel is made default via CONFIG_DEFAULT_NET_SCH > during compile time, or set default during runtime with sysctl > net.core.default_qdisc (see [1]), we get a bad user experience. In my test case > with pfifo_fast, I can transfer thousands of million CAN frames without a frame > drop. On the other hand with fq_codel there is more then one lost CAN frame per > thousand frames. > > As pointed out fq_codel is not suited for CAN hardware, so this patch > introduces a new netdev_priv_flag called "IFF_FIFO_QUEUE" (in contrast to the > existing "IFF_NO_QUEUE"). > > During transition of a netdev from down to up state the default queuing > discipline is attached by attach_default_qdiscs() with the help of > attach_one_default_qdisc(). This patch modifies attach_one_default_qdisc() to > attach the pfifo_fast (pfifo_fast_ops) if the "IFF_FIFO_QUEUE" flag is set. I wonder if we just need to allow arbitrary default qdisc per netdevice while you are on it. A private flag is simply a boolean, perhaps in the future other type of devices wants other default qdiscs, so that could make it more flexible. Just a thought. Thanks.