1STAB(8) Linux STAB(8)
2
6 tc-stab - Generic size table manipulations
7
9 tc qdisc add ... stab
10 [ mtu BYTES ] [ tsize SLOTS ]
11 [ mpu BYTES ] [ overhead BYTES ]
12 [ linklayer { adsl | atm | ethernet } ] ...
13
16 For the description of BYTES - please refer to the UNITS section of
17 tc(8).
18 mtu
21 maximum packet size we create size table for, assumed 2048 if not
22 specified explicitly
23 tsize
25 required table size, assumed 512 if not specified explicitly
26 mpu
28 minimum packet size used in computations
29 overhead
31 per-packet size overhead (can be negative) used in computations
32 linklayer
34 required linklayer specification.
35
37 Size tables allow manipulation of packet sizes, as seen by the whole
38 scheduler framework (of course, the actual packet size remains the
39 same). Adjusted packet size is calculated only once - when a qdisc
40 enqueues the packet. Initial root enqueue initializes it to the real
41 packet's size.
42 Each qdisc can use a different size table, but the adjusted size is
44 stored in an area shared by whole qdisc hierarchy attached to the
45 interface. The effect is that if you have such a setup, the last qdisc
46 with a stab in a chain "wins". For example, consider HFSC with simple
47 pfifo attached to one of its leaf classes. If that pfifo qdisc has
48 stab defined, it will override lengths calculated during HFSC's
49 enqueue; and in turn, whenever HFSC tries to dequeue a packet, it will
50 use a potentially invalid size in its calculations. Normal setups will
51 usually include stab defined only on root qdisc, but further overriding
52 gives extra flexibility for less usual setups.
53 The initial size table is calculated by tc tool using mtu and tsize
55 parameters. The algorithm sets each slot's size to the smallest power
56 of 2 value, so the whole mtu is covered by the size table. Neither
57 tsize, nor mtu have to be power of 2 value, so the size table will usu‐
58 ally support more than is required by mtu.
59 For example, with mtu = 1500 and tsize = 128, a table with 128 slots
61 will be created, where slot 0 will correspond to sizes 0-16, slot 1 to
62 17 - 32, ..., slot 127 to 2033 - 2048. Sizes assigned to each slot
63 depend on linklayer parameter.
64 Stab calculation is also safe for an unusual case, when a size assigned
66 to a slot would be larger than 2^16-1 (you will lose the accuracy
67 though).
68 During the kernel part of packet size adjustment, overhead will be
70 added to original size, and then slot will be calculated. If the size
71 would cause overflow, more than 1 slot will be used to get the final
72 size. This of course will affect accuracy, but it's only a guard
73 against unusual situations.
74 Currently there are two methods of creating values stored in the size
76 table - ethernet and atm (adsl):
77 ethernet
80 This is basically 1-1 mapping, so following our example from above
81 (disregarding mpu for a moment) slot 0 would have 8, slot 1 would
82 have 16 and so on, up to slot 127 with 2048. Note, that mpu > 0
83 must be specified, and slots that would get less than specified by
84 mpu will get mpu instead. If you don't specify mpu, the size table
85 will not be created at all (it wouldn't make any difference),
86 although any overhead value will be respected during calculations.
87 atm, adsl
89 ATM linklayer consists of 53 byte cells, where each of them pro‐
90 vides 48 bytes for payload. Also all the cells must be fully uti‐
91 lized, thus the last one is padded if/as necessary.
92 When the size table is calculated, adjusted size that fits properly
94 into lowest amount of cells is assigned to a slot. For example, a
95 100 byte long packet requires three 48-byte payloads, so the final
96 size would require 3 ATM cells - 159 bytes.
97 For ATM size tables, 16 bytes sized slots are perfectly enough. The
99 default values of mtu and tsize create 4 bytes sized slots.
100
102 The following values are typical for different adsl scenarios (based on
103 [1] and [2]):
104 LLC based:
106 PPPoA - 14 (PPP - 2, ATM - 12)
107 PPPoE - 40+ (PPPoE - 8, ATM - 18, ethernet 14, possibly FCS - 4+padding)
108 Bridged - 32 (ATM - 18, ethernet 14, possibly FCS - 4+padding)
109 IPoA - 16 (ATM - 16)
110 VC Mux based:
112 PPPoA - 10 (PPP - 2, ATM - 8)
113 PPPoE - 32+ (PPPoE - 8, ATM - 10, ethernet 14, possibly FCS - 4+padding)
114 Bridged - 24+ (ATM - 10, ethernet 14, possibly FCS - 4+padding)
115 IPoA - 8 (ATM - 8)
116 There are a few important things regarding the above overheads:
117 · IPoA in LLC case requires SNAP, instead of LLC-NLPID (see rfc2684)
119 - this is the reason why it actually takes more space than PPPoA.
120 · In rare cases, FCS might be preserved on protocols that include
122 Ethernet frames (Bridged and PPPoE). In such situation, any Ether‐
123 net specific padding guaranteeing 64 bytes long frame size has to
124 be included as well (see RFC2684). In the other words, it also
125 guarantees that any packet you send will take minimum 2 atm cells.
126 You should set mpu accordingly for that.
127 · When the size table is consulted, and you're shaping traffic for
129 the sake of another modem/router, an Ethernet header (without pad‐
130 ding) will already be added to initial packet's length. You should
131 compensate for that by subtracting 14 from the above overheads in
132 this case. If you're shaping directly on the router (for example,
133 with speedtouch usb modem) using ppp daemon, you're using raw ip
134 interface without underlying layer2, so nothing will be added.
135 For more thorough explanations, please see [1] and [2].
137
139 It's often forgotten that modern network cards (even cheap ones on
140 desktop motherboards) and/or their drivers often support different
141 offloading mechanisms. In the context of traffic shaping, 'tso' and
142 'gso' might cause undesirable effects, due to massive TCP segments
143 being considered during traffic shaping (including stab calculations).
144 For slow uplink interfaces, it's good to use ethtool to turn off
145 offloading features.
146
148 tc(8), tc-hfsc(7), tc-hfsc(8),
149 [1] http://ace-host.stuart.id.au/russell/files/tc/tc-atm/
150 [2] http://www.faqs.org/rfcs/rfc2684.html
151 Please direct bugreports and patches to: <netdev@vger.kernel.org>
153
155 Manpage created by Michal Soltys (soltys@ziu.info)
156iproute2 31 October 2011 STAB(8)