From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E4DA33B29D for ; Tue, 29 Dec 2020 10:22:00 -0500 (EST) Received: by mail-lf1-x12c.google.com with SMTP id x20so31452008lfe.12 for ; Tue, 29 Dec 2020 07:22:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mBP9CVa/hdxPYXwy5S0K9lD4L2CMYg1yC94IXGX3YOs=; b=Whq9+uVBSkLFn6Cyg/sqqmrvvOXq+D6Zc2u/deTVj5rApj2S/t0sRUpUkZwgMCfnDS 3mgFZCchL0oTPdyrkZuQ7+udC/3dguWtGg6H0bcFvGqQS3gZ4FGENlefee9gjYMB5QMV C3zMcnQn7sUQu4rt7sWF4SkSnjwg75U6t2738Bq//bXmNH2eCK9qi2mQjbIvoxo8APOS 8+0uUwO+bQilh2qDIQXFExJhfx1PsyJlN0IhaXN58t5tQ2Lz28Pjn90GdZBA0j0Ys9pw xKg2ZJsNEHCgFhPsmxUHRhV6d+6VkS6YaDxdtl2PoOFtC3rDLg38SjGvWrzOtjVTgn8q FZfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mBP9CVa/hdxPYXwy5S0K9lD4L2CMYg1yC94IXGX3YOs=; b=Ddt2U1pxI/7Qe9OUHYhySDRaWOrOM4N2fZcV5O/L2TwxXFaqIl88ruyhDYLjtmfjpF owSoeBIZF68aRhU0Lsbe7mG3b5barWbS4cUGbVgv/ZN6e0EN7RaGfn4Q7rbVmOuiDOtR Dulwyu6FxnRPK622xF6ChuLsOuJq+1cAfzXXT1dD1KzDAnUBCKafkuhBZea/oHUwk982 cg/t47Z20Cz6ncJ5i/0wi+q6LBW+ofMFhF9EAuO0sw5d7y+Y0SR4rPjndpqpSaEMany+ NJgM7WUONuUxB/RhABeHeUUIT8aKudLT5pglpawhSokgF5C6CpULIPg5FkPiJNBf/rX4 OYaA== X-Gm-Message-State: AOAM531J/sP14aJiDfj0v9gr4jvNbdD0REPkRAcIKgTNF4IJ/BPpzLJ/ Id9ANECXjbVpdVVMjT8Y46o= X-Google-Smtp-Source: ABdhPJxJUhKloAzKWDjP/0Yebd1PZs3nRpBuKbgWtL+/YZ6ebyOYeos+hcZHirZxF3jGhX+tlBKDAg== X-Received: by 2002:a19:e8e:: with SMTP id 136mr20364673lfo.272.1609255319880; Tue, 29 Dec 2020 07:21:59 -0800 (PST) Received: from jonathartonsmbp.lan (178-55-231-236.bb.dnainternet.fi. [178.55.231.236]) by smtp.gmail.com with ESMTPSA id p13sm6865200ljc.112.2020.12.29.07.21.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Dec 2020 07:21:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) From: Jonathan Morton In-Reply-To: <202012291333.0BTDXwOf077551@gndrsh.dnsmgr.net> Date: Tue, 29 Dec 2020 17:21:57 +0200 Cc: Dave Taht , ECN-Sane Content-Transfer-Encoding: quoted-printable Message-Id: <977989B4-3537-40CC-8877-E78FE00B0A74@gmail.com> References: <202012291333.0BTDXwOf077551@gndrsh.dnsmgr.net> To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> X-Mailer: Apple Mail (2.3445.9.7) Subject: Re: [Ecn-sane] Fwd: [PATCH net] ipv4: Ignore ECN bits for fib lookups in fib_compute_spec_dst() X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 15:22:01 -0000 > On 29 Dec, 2020, at 3:33 pm, Rodney W. Grimes = <4bone@gndrsh.dnsmgr.net> wrote: >=20 > A better fix might be to create some new macros, make the > old macro emmit a compile time warning to weed out the > bad use cases: > a) Modify RT_TOS to assert a compile time warning to > flag old usage. >=20 > b) create RT_TOSBYTE, this returns the whole byte, used > to replace RT_TOS when the whole byte is needed and > dealt with properly. >=20 > c) create RT_TOSTOSBITS, this returns ONLY the TOS bits, > and probably should replace most of the current calls > to RT_TOS with this, after inspecting the code to > make sure it does the right thing. >=20 > d) create RT_TOSECNBITS, this returns ONLY the ECN bits Agree with the principle here, quibble with the terminology. Better = names for these new macros: RT_TOSBYTE RT_TOS_DSFIELD RT_TOS_ECNFIELD This emphasises that the "TOS bits" and Precedence field have been = absorbed into the Diffserv field for the past 20 years already, and that = generally the talk is nowadays of a "field" or a "flag" rather than = "bits". I would seriously consider also making the DSFIELD macro return a = right-justified value, matching most Diffserv documentation tables, = rather than just masking out the left-justified position it occupies = within the TOS byte. This requires a second macro to correctly insert a = fresh right-justified value into the left-justified position, ideally = without disturbing any ECN field value already present. There is some = evidence that mishandling this is a significant source of bugs in user = code, if not also in kernel code. - Jonathan Morton=