From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; dkim=pass header.d=toke.dk; arc=none (Message is not ARC signed); dmarc=pass (Used From Domain Record) header.from=toke.dk policy.dmarc=reject From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1757413942; bh=pvSI6dEFcQ0w2sJJpT5G1SEE2Ew9QDl8F4bK/tvbS60=; h=From:To:Subject:In-Reply-To:References:Date:From; b=VuRf3E3jsAKydPE9KwanxGnfZtfBmoTXHpxTyY9iKg/GK0OYxZVXlrg6VkN0fEVrR 6sYR7t//dNmjYVef454hnvyXkEZ4INHgALXY+EJt2mzW160pib23+X5GXn9YFhksCx WeZlhM7EkWYP3v1W4axErqwc3HLHm0mGdgqVGEW6mrUskivGxiN5RdrwbhsMW5/oWS FBTVbL3v0wsi4GkcNapX8fNd27tzu/MrdLHYyPTvEIhTlU2wKXgeV4m+fMP0VOu8Yl 6nAQ98L8yNqz4MN67lOETWYbONkLa4aDJd1C4OFD4KxjyuwkO/T50LAH5cih+7vXjL V/EJaB1P/3vGQ== To: Matt Corallo , cake@lists.bufferbloat.net In-Reply-To: <78318be7-30d0-4f6a-80f3-063f4558b142@mattcorallo.com> References: <78318be7-30d0-4f6a-80f3-063f4558b142@mattcorallo.com> Date: Tue, 09 Sep 2025 12:32:21 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87cy7zor0q.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Message-ID-Hash: 7MVHBVQP6OJPVBX5UEJ4R65TTJXNZZNI X-Message-ID-Hash: 7MVHBVQP6OJPVBX5UEJ4R65TTJXNZZNI X-MailFrom: toke@toke.dk X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Subject: [Cake] Re: Parsing DSCP out of skb->priority List-Id: Cake - FQ_codel the next generation Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Matt Corallo writes: > Its (presumably) not uncommon to have multiple encapsulation tunnels > running on a host which then wants to do (cake) shaping on the actual > outbound interface. In this case, the skb->hash is (hopefully) > preserved from the original packet to select the right flow queue, but > the DSCP isn't. This is ideally what the priority field of the skb is > for - `skbedit` can set the priority flag of the packet before > "exiting" the tunnel interface, and cake can ultimately read that > priority flag to select a tin. However, doing so requires manual tin > mapping in skbedit, reading the DSCP field and mapping them to the > right tin entirely be hand. > > skbedit also supports `inheritdsfield` which just sets skb->priority > to the DSCP field as-is. It would be nice if cake could read such > priority fields, treating skb->priority as a DSCP when > TC_H_MAJ(skb->priority) is zero (which it always will be in this > case). Is there any interest in a patch to do so? Hmm, we already have quite a few custom ways of assigning packets to tins, so I'm not sure if it's really a good idea to add another one. What you're describing is fairly straight-forward to do with a BPF program, without any performance overhead compared to the mapping cake itself is doing. > Would such a patch need a new userspace option to disable it, or would > wash suffice? We certainly can't assume that any priority value is a diffserv value without some sort of explicit opt-in. And adding an option just for this is really pushing it in the complexity-to-niche-feature trade-off scale :) -Toke