|Subject:||Re: dummy as IMQ replacement|
|From:||Andy Furniss <andy.furniss@xxxxxxxxxxxxx>|
|Date:||Tue, 01 Feb 2005 14:53:29 +0000|
|Cc:||netdev@xxxxxxxxxxx, Nguyen Dinh Nam <nguyendinhnam@xxxxxxxxx>, Remus <rmocius@xxxxxxxxxxxxxx>, Andre Tomt <andre@xxxxxxxx>, syrius.ml@xxxxxxxxxx, Damion de Soto <damion@xxxxxxxxxxxx>|
|References:||<firstname.lastname@example.org> <41FEB3AE.email@example.com> <firstname.lastname@example.org>|
|User-agent:||Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212|
On Mon, 2005-01-31 at 17:39, Andy Furniss wrote:
Ok, but shaping to LARTC posters means being able to classify traffic and set up sharing/priorotising of classes. This is the reason most need to be able to queue - they want to use htb/hfsc for complicated setups and until now were not aware that it was even possible to replicate this in policers and if it becomes feasable it will probably appear daunting to do compared with HTB and all the existing docs/scripts.
For me, I think queuing and dropping is better than just dropping, you can affect tcp by delaying eg. 1 ack per packet rather than delayed acks and clocking out the packets helps smooth burstiness, which hurts latency if you are doing traffic control from the wrong end of the bottleneck.
The idea of loosing the s from sfq and doing multilevel hash/mapping is attractive - of course I would want to queue each flow and have the queue be variable length for each flow depending on occupancy of other flows. I suppose a per flow intelligent dropping scheme would be even better. It would be nice to be able to set/control queuelength for link bandwidth, nothing classful in linux tc does this.
As long as I could use netfilter to mark/classify connections then I think I can sort my setup, don't know about others.
Are pre/post routing sufficient as netfilter hooks for your case?
Yes but depends on where in pre/postrouting. For me after/before nat, as I say above though I could workaround if I classify connections with netfilter. For others as long as they can filter on a mark/classify set in forward, then I think it will be OK for them.
># redirect all IP packets arriving in eth0 to dummy0 ># use mark 1 --> puts them onto class 1:1 >$TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ >match u32 0 0 flowid 1:1 \
What I can do here depends where it hooks packets.
>action ipt -j MARK --set-mark 1 \
I don't know what table I am using - may be OK as long as I can test for a mark I made earlier in the egress dummy case or test connmark/state I set for that connection in the ingress case.
>action mirred egress redirect dev dummy0
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [PATCH 2.6] e100: remove reference to NAPI config option, John W. Linville|
|Next by Date:||Re: dummy as IMQ replacement, Andy Furniss|
|Previous by Thread:||Re: dummy as IMQ replacement, jamal|
|Next by Thread:||Re: dummy as IMQ replacement, jamal|
|Indexes:||[Date] [Thread] [Top] [All Lists]|