<div dir="ltr">><span style="color:rgb(80,0,80);font-size:12.8px">tc qdisc replace dev imq0 root handle 2: cake raw bandwidth $NONCACHE_RATE flows</span><div><span style="color:rgb(80,0,80);font-size:12.8px">here imq0 should be replaced by ifb0 right?.</span></div><div><span style="color:rgb(80,0,80);font-size:12.8px">i will be testing this tonight and reply with results.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 28, 2016 at 4:01 PM, Jonathan Morton <span dir="ltr"><<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 27 Mar, 2016, at 11:20, moeller0 <<a href="mailto:moeller0@gmx.de">moeller0@gmx.de</a>> wrote:<br>
><br>
> it might be more future-proof to just use IFBs from the get-go<br>
<br>
</span>For this particular use-case, it seems to be more complicated to use IFB than IMQ, largely because there is no iptables rule to divert packets through an IFB device, and unlike iptables, the CBQ filter mechanism doesn’t directly support negative matches of any kind.<br>
<br>
However, I think this would work - though it’s completely untested:<br>
<br>
ip link set ifb0 up<br>
<span class=""><br>
tc qdisc replace dev ppp0 root handle 1: cake pppoe-vcmux bandwidth $FULL_RATE triple-isolate<br>
<br>
</span><span class="">tc qdisc replace dev imq0 root handle 2: cake raw bandwidth $NONCACHE_RATE flows<br>
<br>
</span>tc filter replace dev ppp0 protocol ip prio 1 handle 11 u32 match ip src $CACHE_IP/32<br>
<br>
tc filter replace dev ppp0 protocol ip prio 2 handle 12 u32 action mirred egress redirect dev ifb0<br>
<br>
The logic of the above is that a positive match is made on the cache traffic, but no action is taken.  This terminates filter processing for that traffic.  The remaining traffic is redirected unconditionally to the IFB device by the second filter rule.<br>
<br>
One thing I’m not entirely certain of is whether traffic that has been through an IFB device is then requeued in the normal way on the original device.  I’d appreciate feedback on whether this system does in fact work.<br>
<span class=""><br>
> I would respectfully recommend to avoid the symbolic overhead parameters<br>
<br>
</span>Even if I change their underlying behaviour in the future, it’ll be in a way that retains backwards compatibility with all the examples I’ve given for the current scheme.  I mostly wanted to raise awareness that the overhead compensation system exists for use on encapsulated links.<br>
<span class="HOEnZb"><font color="#888888"><br>
 - Jonathan Morton<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Thanx and regd's.<br><br>Allan.<br><br></div></div>
</div>