flent-users writes: > HI Toke, > > >> On Sep 3, 2018, at 19:37, Toke Høiland-Jørgensen wrote: >> >> flent-users writes: >> >> > Hi Dave, >> > >> > >> >> On Sep 3, 2018, at 18:00, Dave Täht wrote: >> >> vnv >> >> Another rrul_v2 issue would be to correctly end up in all the queues on wifi. >> > >> > So in theory rrul_cs8 should do that... (it aims to just use one >> > dscp-marked flow per class selector for a total of 8 tcp flows per >> > direction...) In practice I believe the mapping from dscps to ACs is >> > highly non-linear... >> >> Well, not that non-linear: >> >> const int ieee802_1d_to_ac[8] = { >> IEEE80211_AC_BE, >> IEEE80211_AC_BK, >> IEEE80211_AC_BK, >> IEEE80211_AC_BE, >> IEEE80211_AC_VI, >> IEEE80211_AC_VI, >> IEEE80211_AC_VO, >> IEEE80211_AC_VO >> }; > > Well, aren't these values according to IEEE P802.1p (https://en.wikipedia.org/wiki/IEEE_P802.1p)? > > PCP value Priority Acronym Traffic types > 1 0 (lowest) BK Background > 0 1 (default) BE Best effort > 2 2 EE Excellent effort > 3 3 CA Critical applications > 4 4 VI Video, < 100 ms latency and jitter > 5 5 VO Voice, < 10 ms latency and jitter > 6 6 IC Internetwork control > 7 7 (highest) NC Network control > > These map the 3 bit priority PCP values from VLAN tags to ACs, but > note the dance with PCP 1 being lower than PCP 0, and more importantly > the different interpretations about PCP 2, is it "excellent effort" or > another BK code point? > > I guess the point I wanted to make is that mapping down from the 6bit > DSCP to ACs is not very intuitive (with linear mapping being the "most > intuitive"). > > Anyway, I am totally fine with just using 3 bits, this is still plenty > for priority hierarchies that I can still understand ;) Oh, it's absolutely a mess. So much so that the IETF had to write a whole RFC on it: https://tools.ietf.org/html/rfc8325 -Toke -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/tohojo/flent/issues/148#issuecomment-418188201