1STAB(8)                              Linux                             STAB(8)
2
3
4

NAME

6       tc-stab - Generic size table manipulations
7

SYNOPSIS

9       tc qdisc add ... stab
10           [ mtu BYTES ] [ tsize SLOTS ]
11           [ mpu BYTES ] [ overhead BYTES ]
12           [ linklayer { adsl | atm | ethernet } ] ...
13
14

OPTIONS

16       For  the  description  of  BYTES - please refer to the UNITS section of
17       tc(8).
18
19
20       mtu
21           maximum packet size we create size table for, assumed 2048  if  not
22           specified explicitly
23
24       tsize
25           required table size, assumed 512 if not specified explicitly
26
27       mpu
28           minimum packet size used in computations
29
30       overhead
31           per-packet size overhead (can be negative) used in computations
32
33       linklayer
34           required linklayer specification.
35

DESCRIPTION

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
43       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
54       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
60       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
65       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
69       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
75       Currently  there  are two methods of creating values stored in the size
76       table - ethernet and atm (adsl):
77
78
79       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
88       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
93           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
98           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

TYPICAL OVERHEADS

102       The following values are typical for different adsl scenarios (based on
103       [1] and [2]):
104
105       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
111       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
118       ·   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
121       ·   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
128       ·   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
136           For more thorough explanations, please see [1] and [2].
137

ETHERNET CARDS CONSIDERATIONS

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

SEE ALSO

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
152       Please direct bugreports and patches to: <netdev@vger.kernel.org>
153

AUTHOR

155       Manpage created by Michal Soltys (soltys@ziu.info)
156
157
158
159iproute2                        31 October 2011                        STAB(8)
Impressum