mirror of
				https://git.proxmox.com/git/mirror_iproute2
				synced 2025-11-04 06:22:48 +00:00 
			
		
		
		
	No other man pages do so, hiding netdev is kind of silly and I don't mind having my own address normally visible.
		
			
				
	
	
		
			164 lines
		
	
	
		
			6.4 KiB
		
	
	
	
		
			Groff
		
	
	
	
	
	
			
		
		
	
	
			164 lines
		
	
	
		
			6.4 KiB
		
	
	
	
		
			Groff
		
	
	
	
	
	
.TH STAB 8 "31 October 2011" iproute2 Linux
 | 
						|
.
 | 
						|
.SH NAME
 | 
						|
tc\-stab \- Generic size table manipulations
 | 
						|
.
 | 
						|
.SH SYNOPSIS
 | 
						|
.nf
 | 
						|
tc qdisc add ... stab
 | 
						|
.RS 4
 | 
						|
[ \fBmtu\fR BYTES ] [ \fBtsize\fR SLOTS ]
 | 
						|
[ \fBmpu\fR BYTES ] [ \fBoverhead\fR BYTES ]
 | 
						|
[ \fBlinklayer\fR { adsl | atm | ethernet } ] ...
 | 
						|
.RE
 | 
						|
.fi
 | 
						|
 | 
						|
.SH OPTIONS
 | 
						|
For the description of BYTES \- please refer to the \fBUNITS\fR
 | 
						|
section of \fBtc\fR(8).
 | 
						|
 | 
						|
.IP \fBmtu\fR 4
 | 
						|
.br
 | 
						|
maximum packet size we create size table for, assumed 2048 if not specified explicitly
 | 
						|
.IP \fBtsize\fR
 | 
						|
.br
 | 
						|
required table size, assumed 512 if not specified explicitly
 | 
						|
.IP \fBmpu\fR
 | 
						|
.br
 | 
						|
minimum packet size used in computations
 | 
						|
.IP \fBoverhead\fR
 | 
						|
.br
 | 
						|
per\-packet size overhead (can be negative) used in computations
 | 
						|
.IP \fBlinklayer\fR
 | 
						|
.br
 | 
						|
required linklayer specification.
 | 
						|
.PP
 | 
						|
.
 | 
						|
.SH DESCRIPTION
 | 
						|
.
 | 
						|
Size tables allow manipulation of packet sizes, as seen by the whole scheduler
 | 
						|
framework (of course, the actual packet size remains the same). Adjusted packet
 | 
						|
size is calculated only once \- when a qdisc enqueues the packet. Initial root
 | 
						|
enqueue initializes it to the real packet's size.
 | 
						|
 | 
						|
Each qdisc can use a different size table, but the adjusted size is stored in
 | 
						|
an area shared by whole qdisc hierarchy attached to the interface. The effect is
 | 
						|
that if you have such a setup, the last qdisc with a stab in a chain "wins". For
 | 
						|
example, consider HFSC with simple pfifo attached to one of its leaf classes.
 | 
						|
If that pfifo qdisc has stab defined, it will override lengths calculated
 | 
						|
during HFSC's enqueue; and in turn, whenever HFSC tries to dequeue a packet, it
 | 
						|
will use a potentially invalid size in its calculations. Normal setups will
 | 
						|
usually include stab defined only on root qdisc, but further overriding gives
 | 
						|
extra flexibility for less usual setups.
 | 
						|
 | 
						|
The initial size table is calculated by \fBtc\fR tool using \fBmtu\fR and
 | 
						|
\fBtsize\fR parameters. The algorithm sets each slot's size to the smallest
 | 
						|
power of 2 value, so the whole \fBmtu\fR is covered by the size table. Neither
 | 
						|
\fBtsize\fR, nor \fBmtu\fR have to be power of 2 value, so the size
 | 
						|
table will usually support more than is required by \fBmtu\fR.
 | 
						|
 | 
						|
For example, with \fBmtu\fR\~=\~1500 and \fBtsize\fR\~=\~128, a table with 128
 | 
						|
slots will be created, where slot 0 will correspond to sizes 0\-16, slot 1 to
 | 
						|
17\~\-\~32, \&..., slot 127 to 2033\~\-\~2048. Sizes assigned to each slot
 | 
						|
depend on \fBlinklayer\fR parameter.
 | 
						|
 | 
						|
Stab calculation is also safe for an unusual case, when a size assigned to a
 | 
						|
slot would be larger than 2^16\-1 (you will lose the accuracy though).
 | 
						|
 | 
						|
During the kernel part of packet size adjustment, \fBoverhead\fR will be added
 | 
						|
to original size, and then slot will be calculated. If the size would cause
 | 
						|
overflow, more than 1 slot will be used to get the final size. This of course
 | 
						|
will affect accuracy, but it's only a guard against unusual situations.
 | 
						|
 | 
						|
Currently there are two methods of creating values stored in the size table \-
 | 
						|
ethernet and atm (adsl):
 | 
						|
 | 
						|
.IP ethernet 4
 | 
						|
.br
 | 
						|
This is basically 1\-1 mapping, so following our example from above
 | 
						|
(disregarding \fBmpu\fR for a moment) slot 0 would have 8, slot 1 would have 16
 | 
						|
and so on, up to slot 127 with 2048. Note, that \fBmpu\fR\~>\~0 must be
 | 
						|
specified, and slots that would get less than specified by \fBmpu\fR will get
 | 
						|
\fBmpu\fR instead. If you don't specify \fBmpu\fR, the size table will not be
 | 
						|
created at all (it wouldn't make any difference), although any \fBoverhead\fR
 | 
						|
value will be respected during calculations.
 | 
						|
.IP "atm, adsl"
 | 
						|
.br
 | 
						|
ATM linklayer consists of 53 byte cells, where each of them provides 48 bytes
 | 
						|
for payload. Also all the cells must be fully utilized, thus the last one is
 | 
						|
padded if/as necessary.
 | 
						|
 | 
						|
When the size table is calculated, adjusted size that fits properly into lowest
 | 
						|
amount of cells is assigned to a slot. For example, a 100 byte long packet
 | 
						|
requires three 48\-byte payloads, so the final size would require 3 ATM cells
 | 
						|
\- 159 bytes.
 | 
						|
 | 
						|
For ATM size tables, 16\~bytes sized slots are perfectly enough. The default
 | 
						|
values of \fBmtu\fR and \fBtsize\fR create 4\~bytes sized slots.
 | 
						|
.PP
 | 
						|
.
 | 
						|
.SH "TYPICAL OVERHEADS"
 | 
						|
The following values are typical for different adsl scenarios (based on
 | 
						|
\fB[1]\fR and \fB[2]\fR):
 | 
						|
 | 
						|
.nf
 | 
						|
LLC based:
 | 
						|
.RS 4
 | 
						|
PPPoA \- 14 (PPP \- 2, ATM \- 12)
 | 
						|
PPPoE \- 40+ (PPPoE \- 8, ATM \- 18, ethernet 14, possibly FCS \- 4+padding)
 | 
						|
Bridged \- 32 (ATM \- 18, ethernet 14, possibly FCS \- 4+padding)
 | 
						|
IPoA \- 16 (ATM \- 16)
 | 
						|
.RE
 | 
						|
 | 
						|
VC Mux based:
 | 
						|
.RS 4
 | 
						|
PPPoA \- 10 (PPP \- 2, ATM \- 8)
 | 
						|
PPPoE \- 32+ (PPPoE \- 8, ATM \- 10, ethernet 14, possibly FCS \- 4+padding)
 | 
						|
Bridged \- 24+ (ATM \- 10, ethernet 14, possibly FCS \- 4+padding)
 | 
						|
IPoA \- 8 (ATM \- 8)
 | 
						|
.RE
 | 
						|
.fi
 | 
						|
There are a few important things regarding the above overheads:
 | 
						|
.
 | 
						|
.IP \(bu 4
 | 
						|
IPoA in LLC case requires SNAP, instead of LLC\-NLPID (see rfc2684) \- this is
 | 
						|
the reason why it actually takes more space than PPPoA.
 | 
						|
.IP \(bu
 | 
						|
In rare cases, FCS might be preserved on protocols that include Ethernet frames
 | 
						|
(Bridged and PPPoE). In such situation, any Ethernet specific padding
 | 
						|
guaranteeing 64 bytes long frame size has to be included as well (see RFC2684).
 | 
						|
In the other words, it also guarantees that any packet you send will take
 | 
						|
minimum 2 atm cells. You should set \fBmpu\fR accordingly for that.
 | 
						|
.IP \(bu
 | 
						|
When the size table is consulted, and you're shaping traffic for the sake of
 | 
						|
another modem/router, an Ethernet header (without padding) will already be added
 | 
						|
to initial packet's length. You should compensate for that by subtracting 14
 | 
						|
from the above overheads in this case. If you're shaping directly on the router
 | 
						|
(for example, with speedtouch usb modem) using ppp daemon, you're using raw ip
 | 
						|
interface without underlying layer2, so nothing will be added.
 | 
						|
 | 
						|
For more thorough explanations, please see \fB[1]\fR and \fB[2]\fR.
 | 
						|
.
 | 
						|
.SH "ETHERNET CARDS CONSIDERATIONS"
 | 
						|
.
 | 
						|
It's often forgotten that modern network cards (even cheap ones on desktop
 | 
						|
motherboards) and/or their drivers often support different offloading
 | 
						|
mechanisms. In the context of traffic shaping, 'tso' and 'gso' might cause
 | 
						|
undesirable effects, due to massive TCP segments being considered during
 | 
						|
traffic shaping (including stab calculations). For slow uplink interfaces,
 | 
						|
it's good to use \fBethtool\fR to turn off offloading features.
 | 
						|
.
 | 
						|
.SH "SEE ALSO"
 | 
						|
.
 | 
						|
\fBtc\fR(8), \fBtc\-hfsc\fR(7), \fBtc\-hfsc\fR(8),
 | 
						|
.br
 | 
						|
\fB[1]\fR http://ace\-host.stuart.id.au/russell/files/tc/tc\-atm/
 | 
						|
.br
 | 
						|
\fB[2]\fR http://www.faqs.org/rfcs/rfc2684.html
 | 
						|
 | 
						|
Please direct bugreports and patches to: <netdev@vger.kernel.org>
 | 
						|
.
 | 
						|
.SH "AUTHOR"
 | 
						|
.
 | 
						|
Manpage created by Michal Soltys (soltys@ziu.info)
 |