On 9/12/12 4:26 PM, Mr Dash Four wrote: >> then you will know everything about HFSC as I do (although there is >> some of my analysis available at > At?
Disregard -- I reworded that part and neglected to clean it up. > >> The PRIORITY value is still used for generating the priority of the >> Shorewall-generated filters that classify traffic by MARK and by >> the tcp-ack and tos options. It just isn't used for by the queuing >> discipline. So I prefer to handle this via a documentation change. >> I have made the PRIORITY optional for HFSC classes and allowed an >> explicit prority to be specified for MARK and the two options. > > 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. These are *filters* that associate individuals with classes; they are queuing-discipline independent. > > 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. My enthusiasm for traffic shaping rivals my love of undergoing oral surgery (I didn't implement the original TC -- after the TC developer created it, he promptly disappeared). > > Also, a side question - is there any reason why the priority should > be calculated in this way - value << 8 | 20? Only to make it be evaluated after value << 8 | 10 and to ensure uniqueness between class priorities. > >> You can use CBQ but Shorewall has no support for it. So you would >> need to script the rules in /etc/shorewall/tcscript and set >> TC_ENABLED=Yes in shorewall.conf. > > CBQ seems to be a bit more comprehensive, though I haven't looked in > details about this discipline. I may consider it. > >>> Another question - you use "tc filter" for ifbX type devices, but >>> not for others. Why? >> >> 'tc filter' is the only way to classify ifbX traffic. So the >> documentation stresses that application. > 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. > >>> Can you not use hfsc for definition of classes and then create >>> separate "tc filter" statements when you can define priorities. >> >> Sure. > Again, I meant for "normal" devices. Would that work? Yes -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
