{ "content": [ { "type": "text", "text": "# tc-stab (man)\n\n## NAME\n\ntc-stab - Generic size table manipulations\n\n## SYNOPSIS\n\ntc qdisc add ... stab\n[ mtu BYTES ] [ tsize SLOTS ]\n[ mpu BYTES ] [ overhead BYTES ]\n[ linklayer { adsl | atm | ethernet } ] ...\n\n## DESCRIPTION\n\nSize tables allow manipulation of packet sizes, as seen by the whole scheduler framework (of\ncourse, the actual packet size remains the same). Adjusted packet size is calculated only\nonce - when a qdisc enqueues the packet. Initial root enqueue initializes it to the real\npacket's size.\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **OPTIONS** (5 subsections)\n- **DESCRIPTION**\n- **TYPICAL OVERHEADS**\n- **ETHERNET CARDS CONSIDERATIONS**\n- **SEE ALSO**\n- **AUTHOR**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "tc-stab", "section": "", "mode": "man", "summary": "tc-stab - Generic size table manipulations", "synopsis": "tc qdisc add ... stab\n[ mtu BYTES ] [ tsize SLOTS ]\n[ mpu BYTES ] [ overhead BYTES ]\n[ linklayer { adsl | atm | ethernet } ] ...", "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [], "examples": [], "see_also": [ { "name": "tc", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/tc/8/json" }, { "name": "tc-hfsc", "section": "7", "url": "https://www.chedong.com/phpMan.php/man/tc-hfsc/7/json" }, { "name": "tc-hfsc", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/tc-hfsc/8/json" } ], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "SYNOPSIS", "lines": 6, "subsections": [] }, { "name": "OPTIONS", "lines": 3, "subsections": [ { "name": "mtu", "lines": 2 }, { "name": "tsize", "lines": 2 }, { "name": "mpu", "lines": 2 }, { "name": "overhead", "lines": 2 }, { "name": "linklayer", "lines": 2 } ] }, { "name": "DESCRIPTION", "lines": 55, "subsections": [] }, { "name": "TYPICAL OVERHEADS", "lines": 33, "subsections": [] }, { "name": "ETHERNET CARDS CONSIDERATIONS", "lines": 6, "subsections": [] }, { "name": "SEE ALSO", "lines": 6, "subsections": [] }, { "name": "AUTHOR", "lines": 3, "subsections": [] } ], "sections": { "NAME": { "content": "tc-stab - Generic size table manipulations\n", "subsections": [] }, "SYNOPSIS": { "content": "tc qdisc add ... stab\n[ mtu BYTES ] [ tsize SLOTS ]\n[ mpu BYTES ] [ overhead BYTES ]\n[ linklayer { adsl | atm | ethernet } ] ...\n\n", "subsections": [] }, "OPTIONS": { "content": "For the description of BYTES - please refer to the UNITS section of tc(8).\n\n", "subsections": [ { "name": "mtu", "content": "maximum packet size we create size table for, assumed 2048 if not specified explicitly\n" }, { "name": "tsize", "content": "required table size, assumed 512 if not specified explicitly\n" }, { "name": "mpu", "content": "minimum packet size used in computations\n" }, { "name": "overhead", "content": "per-packet size overhead (can be negative) used in computations\n" }, { "name": "linklayer", "content": "required linklayer specification.\n" } ] }, "DESCRIPTION": { "content": "Size tables allow manipulation of packet sizes, as seen by the whole scheduler framework (of\ncourse, the actual packet size remains the same). Adjusted packet size is calculated only\nonce - when a qdisc enqueues the packet. Initial root enqueue initializes it to the real\npacket's size.\n\nEach qdisc can use a different size table, but the adjusted size is stored in an area shared\nby whole qdisc hierarchy attached to the interface. The effect is that if you have such a\nsetup, the last qdisc with a stab in a chain \"wins\". For example, consider HFSC with simple\npfifo attached to one of its leaf classes. If that pfifo qdisc has stab defined, it will\noverride lengths calculated during HFSC's enqueue; and in turn, whenever HFSC tries to de‐\nqueue a packet, it will use a potentially invalid size in its calculations. Normal setups\nwill usually include stab defined only on root qdisc, but further overriding gives extra\nflexibility for less usual setups.\n\nThe initial size table is calculated by tc tool using mtu and tsize parameters. The algorithm\nsets each slot's size to the smallest power of 2 value, so the whole mtu is covered by the\nsize table. Neither tsize, nor mtu have to be power of 2 value, so the size table will usu‐\nally support more than is required by mtu.\n\nFor example, with mtu = 1500 and tsize = 128, a table with 128 slots will be created, where\nslot 0 will correspond to sizes 0-16, slot 1 to 17 - 32, ..., slot 127 to 2033 - 2048. Sizes\nassigned to each slot depend on linklayer parameter.\n\nStab calculation is also safe for an unusual case, when a size assigned to a slot would be\nlarger than 2^16-1 (you will lose the accuracy though).\n\nDuring the kernel part of packet size adjustment, overhead will be added to original size,\nand then slot will be calculated. If the size would cause overflow, more than 1 slot will be\nused to get the final size. This of course will affect accuracy, but it's only a guard\nagainst unusual situations.\n\nCurrently there are two methods of creating values stored in the size table - ethernet and\natm (adsl):\n\n\nethernet\nThis is basically 1-1 mapping, so following our example from above (disregarding mpu for\na moment) slot 0 would have 8, slot 1 would have 16 and so on, up to slot 127 with 2048.\nNote, that mpu > 0 must be specified, and slots that would get less than specified by mpu\nwill get mpu instead. If you don't specify mpu, the size table will not be created at all\n(it wouldn't make any difference), although any overhead value will be respected during\ncalculations.\n\natm, adsl\nATM linklayer consists of 53 byte cells, where each of them provides 48 bytes for pay‐\nload. Also all the cells must be fully utilized, thus the last one is padded if/as neces‐\nsary.\n\nWhen the size table is calculated, adjusted size that fits properly into lowest amount of\ncells is assigned to a slot. For example, a 100 byte long packet requires three 48-byte\npayloads, so the final size would require 3 ATM cells - 159 bytes.\n\nFor ATM size tables, 16 bytes sized slots are perfectly enough. The default values of mtu\nand tsize create 4 bytes sized slots.\n", "subsections": [] }, "TYPICAL OVERHEADS": { "content": "The following values are typical for different adsl scenarios (based on [1] and [2]):\n\nLLC based:\nPPPoA - 14 (PPP - 2, ATM - 12)\nPPPoE - 40+ (PPPoE - 8, ATM - 18, ethernet 14, possibly FCS - 4+padding)\nBridged - 32 (ATM - 18, ethernet 14, possibly FCS - 4+padding)\nIPoA - 16 (ATM - 16)\n\nVC Mux based:\nPPPoA - 10 (PPP - 2, ATM - 8)\nPPPoE - 32+ (PPPoE - 8, ATM - 10, ethernet 14, possibly FCS - 4+padding)\nBridged - 24+ (ATM - 10, ethernet 14, possibly FCS - 4+padding)\nIPoA - 8 (ATM - 8)\nThere are a few important things regarding the above overheads:\n\n• IPoA in LLC case requires SNAP, instead of LLC-NLPID (see rfc2684) - this is the reason\nwhy it actually takes more space than PPPoA.\n\n• In rare cases, FCS might be preserved on protocols that include Ethernet frames (Bridged\nand PPPoE). In such situation, any Ethernet specific padding guaranteeing 64 bytes long\nframe size has to be included as well (see RFC2684). In the other words, it also guaran‐\ntees that any packet you send will take minimum 2 atm cells. You should set mpu accord‐\ningly for that.\n\n• When the size table is consulted, and you're shaping traffic for the sake of another mo‐\ndem/router, an Ethernet header (without padding) will already be added to initial\npacket's length. You should compensate for that by subtracting 14 from the above over‐\nheads in this case. If you're shaping directly on the router (for example, with speed‐\ntouch usb modem) using ppp daemon, you're using raw ip interface without underlying\nlayer2, so nothing will be added.\n\nFor more thorough explanations, please see [1] and [2].\n", "subsections": [] }, "ETHERNET CARDS CONSIDERATIONS": { "content": "It's often forgotten that modern network cards (even cheap ones on desktop motherboards)\nand/or their drivers often support different offloading mechanisms. In the context of traffic\nshaping, 'tso' and 'gso' might cause undesirable effects, due to massive TCP segments being\nconsidered during traffic shaping (including stab calculations). For slow uplink interfaces,\nit's good to use ethtool to turn off offloading features.\n", "subsections": [] }, "SEE ALSO": { "content": "tc(8), tc-hfsc(7), tc-hfsc(8),\n[1] http://ace-host.stuart.id.au/russell/files/tc/tc-atm/\n[2] http://www.faqs.org/rfcs/rfc2684.html\n\nPlease direct bugreports and patches to: \n", "subsections": [] }, "AUTHOR": { "content": "Manpage created by Michal Soltys (soltys@ziu.info)\n\niproute2 31 October 2011 STAB(8)", "subsections": [] } } } }