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 1476
I 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
