>> In other words, for any other classes (i.e. HTB in this case as HFSC >> has no use for it), you use this value << 8 | 20 to determine the >> class priority, right? > > Also for HFSC. My understanding was that you ignore the PRIORITY column in tcclasses for HFSC as it doesn't support it.
> These are *filters* that associate individuals with > classes; they are queuing-discipline independent. Yes, I am aware of that, though I thought that you use the value specified in PRIORITY << 8 | 20 and use the result in the "prio" option when defining the class, is that not the case or have I got this wrong? >> If so, can you not do the same with the "tc filter" priorities >> instead of having two separate values specified in 2 separate files? >> In other words, what I am asking is this - why have a separate column >> in tcfilters when you can use the value in this one (PRIORITY column >> in tcclasses) and then calculate the << 8 | 20 magic from it and then >> use that in the "tc filter" statements? Reduces complexity and >> everything is in one place. > > Because I don't have the energy for all of the testing that would take. Well, I am able to help with the testing part, if needed - you know that. The idea is to use a single value (PRIORITY in tcclasses) for class as well as filter "prio" options, instead of using PRIORITY in tcclasses for class priorities and have a separate PRIORITY value in tcfilters for the filter "prio" options, simply because in most cases these priorities will be the same. > Only to make it be evaluated after value << 8 | 10 and to ensure > uniqueness between class priorities. "Be evaluated"? Are there any restrictions on these values? I know of one - in filters - that needs to be > 12. Are there any other such restrictions? >> I understand that, but my question was more towards if you use it for >> ifbX device why not use it for "normal" ones - like eth0 for example? >> That way, priorities can be specified regardless of the queuing >> discipline used, right? > > If you like them, use them. Currently, for outgoing traffic, CLASSIFY target is used, which derives its constraints from tcrules. If HFSC is not used, then the priority specified in tclasses is applied - in one form or another - in "prio" option when the class is defined. That's of no use if HFSC discipline is defined. Can you not, in such a case, define a "dummy" "tc filter" statement corresponding to that class, setting the priority specified? Something like: run_tc filter add dev eth0 protocol ip parent e:0 prio <PRIORITY in tclasses << 8 | 20> flowid <classid from tcclasses>? Would that work? If so, this is how you can always use priorities regardless of the queuing discipline defined. Would that work, is this doable? ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
