Re: Some more test on ingress, ifb, fwmark
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Marco Gaiarin wrote:
for the tx buffer, you mean that ''doesn't bother'', or i've to set accordingly the sfq buffer with the 'limit' paremeter? But i don't define a sfq for the parent, i've to setup the limit parameter for every children?
Setting it as you did is probably OK, I was just pointing out that lengths of the sfqs would be sfqs default and not that.
If you had not had sfqs then htb would have used txqlen as buffer lengths. I don't think it will make any difference for the parent (but haven't tested that).
/sbin/tc class add dev ifb2 parent 1: classid 1:1 htb rate 3000kbit ceil 3000kbit burst 16k cburst 8k mtu 1476I also wouldn't set mtu here it's not the same meaning as doing it on a real if - IIRC it also needs 14 adding for traffic on/from eth)This is true also for the egress shaping, for eth2? Eg, setting mtu on the parent class for eth2 mean nothing?
It does mean something as htb will adjust some of its own internal settings/calculations, but changing from default (1514) to 1476 probably won't make much difference - maybe if you wanted really big for jumbo frames or tso then it would be worth doing.
As I said you would also need to add 14 to the ip level mtu as on eth (and I guess ifb traffic redirected from eth) htb sees packet lengths +14 (src/dst mac + protocol).
It's not like setting mtu on real eth which of course takes ip length and may cause fragmentation/icmp frag needed if something bigger tries to pass.
With policers mtu is important in that setting too small will just drop anything oversize.
What are the best strategy to compute burst/cburst and buffers, if there's one?
I don't know. I just set high (few k) for interactive traffic and low (but not 0) for bulk.
-- To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html