Mmmh,
> On Jan 25, 2022, at 11:58, Toke Høiland-Jørgensen <t...@redhat.com> wrote: > > Matt Johnston <m...@codeconstruct.com.au> writes: > >> The CS1 priority (index 0x08) was changed from 0 to 1 when LE (index >> 0x01) was added. This looks unintentional, it doesn't match the >> docs and CS1 shouldn't be the same tin as AF1x > > Hmm, Kevin, any comments? I am clearly not Kevin, but.... https://elixir.bootlin.com/linux/v5.16.2/source/net/sched/sch_cake.c static const u8 diffserv8[] = { 2, 0, 1, 2, 4, 2, 2, 2, 1, 2, 1, 2, 1, 2, 1, 2, 5, 2, 4, 2, 4, 2, 4, 2, 3, 2, 3, 2, 3, 2, 3, 2, 6, 2, 3, 2, 3, 2, 3, 2, 6, 2, 2, 2, 6, 2, 6, 2, 7, 2, 2, 2, 2, 2, 2, 2, 7, 2, 2, 2, 2, 2, 2, 2, }; LE(1) is tin 0 the lowest CS1(8) is 1 slightly above LE CS0/BE(0) is 2 AF1x (10, 12, 14) are all in tin 1 as is CS1 AF2x (18, 20, 22) in tin4 AF3x (26, 28, 30) in tin3 AF4x (34, 36, 38) in tin3 Just as documented in the code: { /* Pruned list of traffic classes for typical applications: * * Network Control (CS6, CS7) * Minimum Latency (EF, VA, CS5, CS4) * Interactive Shell (CS2, TOS1) * Low Latency Transactions (AF2x, TOS4) * Video Streaming (AF4x, AF3x, CS3) * Bog Standard (CS0 etc.) * High Throughput (AF1x, TOS2) * Background Traffic (CS1, LE) * * Total 8 traffic classes. */ I note that this seems backwards, as I assumed the AFN to be in increasing order of priority, but at the same time I care very little for he 12 AF codepoints, they are not reliably end to end, and many important devices only allow 3 priority bits anyway, so I question whether they actually ever see much use at all, but that is tangential... BUT IMHO the main reason for introducing LE in the first place was/is that CS1 often is interpreted as higher priority than CS0 (e.g. by gear that looks at the 3 highest TOS bits), resulting in an priority inversion where BK packets end up with higher priority than BE in spite of the senders intention being the other way round. Having CS1 in the same tin/priority tier as CS0 seems harmless (priorities are not guaranteed e2e anyway, so CS1/LE will be routinely treated equally as CS0/BE already and senders will need to have made peace with that already). So I argue with the introduction of LE, CS1 should be treated equivalently to CS0 (giving it higher priority will actively do the wrong thing for senders still using CS1 for background). So I agree that there is potential for cahnge, but that change should IMHO be to move CS1 to tin2 in diffserv8... BUT to be really, really frank, none of this matters much, since DSCPs are not stable end to end, so local remapping seems required anyway, and then the re-mapper needs to look at the actual mapping scheme independent of the narratives given for different DSCPs/PHBs in IETF documents (affectionately called "DSCP-fan-fiction"). Regards Sebastian > > -Toke > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
