annotate Documentation/networking/policy-routing.txt @ 897:329ea0ccb344

balloon: try harder to balloon up under memory pressure.

Currently if the balloon driver is unable to increase the guest's
reservation it assumes the failure was due to reaching its full
allocation, gives up on the ballooning operation and records the limit
it reached as the "hard limit". The driver will not try again until
the target is set again (even to the same value).

However it is possible that ballooning has in fact failed due to
memory pressure in the host and therefore it is desirable to keep
attempting to reach the target in case memory becomes available. The
most likely scenario is that some guests are ballooning down while
others are ballooning up and therefore there is temporary memory
pressure while things stabilise. You would not expect a well behaved
toolstack to ask a domain to balloon to more than its allocation nor
would you expect it to deliberately over-commit memory by setting
balloon targets which exceed the total host memory.

This patch drops the concept of a hard limit and causes the balloon
driver to retry increasing the reservation on a timer in the same
manner as when decreasing the reservation.

Also if we partially succeed in increasing the reservation
(i.e. receive less pages than we asked for) then we may as well keep
those pages rather than returning them to Xen.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
author Keir Fraser <keir.fraser@citrix.com>
date Fri Jun 05 14:01:20 2009 +0100 (2009-06-05)
parents 831230e53067
rev   line source
ian@0 1 Classes
ian@0 2 -------
ian@0 3
ian@0 4 "Class" is a complete routing table in common sense.
ian@0 5 I.e. it is tree of nodes (destination prefix, tos, metric)
ian@0 6 with attached information: gateway, device etc.
ian@0 7 This tree is looked up as specified in RFC1812
ian@0 8 1. Basic match
ian@0 9 2. Longest match
ian@0 10 3. Weak TOS.
ian@0 11 4. Metric. (should not be in kernel space, but they are)
ian@0 12 5. Additional pruning rules. (not in kernel space).
ian@0 13
ian@0 14 We have two special type of nodes:
ian@0 15 REJECT - abort route lookup and return an error value.
ian@0 16 THROW - abort route lookup in this class.
ian@0 17
ian@0 18
ian@0 19 Currently the number of classes is limited to 255
ian@0 20 (0 is reserved for "not specified class")
ian@0 21
ian@0 22 Three classes are builtin:
ian@0 23
ian@0 24 RT_CLASS_LOCAL=255 - local interface addresses,
ian@0 25 broadcasts, nat addresses.
ian@0 26
ian@0 27 RT_CLASS_MAIN=254 - all normal routes are put there
ian@0 28 by default.
ian@0 29
ian@0 30 RT_CLASS_DEFAULT=253 - if ip_fib_model==1, then
ian@0 31 normal default routes are put there, if ip_fib_model==2
ian@0 32 all gateway routes are put there.
ian@0 33
ian@0 34
ian@0 35 Rules
ian@0 36 -----
ian@0 37 Rule is a record of (src prefix, src interface, tos, dst prefix)
ian@0 38 with attached information.
ian@0 39
ian@0 40 Rule types:
ian@0 41 RTP_ROUTE - lookup in attached class
ian@0 42 RTP_NAT - lookup in attached class and if a match is found,
ian@0 43 translate packet source address.
ian@0 44 RTP_MASQUERADE - lookup in attached class and if a match is found,
ian@0 45 masquerade packet as sourced by us.
ian@0 46 RTP_DROP - silently drop the packet.
ian@0 47 RTP_REJECT - drop the packet and send ICMP NET UNREACHABLE.
ian@0 48 RTP_PROHIBIT - drop the packet and send ICMP COMM. ADM. PROHIBITED.
ian@0 49
ian@0 50 Rule flags:
ian@0 51 RTRF_LOG - log route creations.
ian@0 52 RTRF_VALVE - One way route (used with masquerading)
ian@0 53
ian@0 54 Default setup:
ian@0 55
ian@0 56 root@amber:/pub/ip-routing # iproute -r
ian@0 57 Kernel routing policy rules
ian@0 58 Pref Source Destination TOS Iface Cl
ian@0 59 0 default default 00 * 255
ian@0 60 254 default default 00 * 254
ian@0 61 255 default default 00 * 253
ian@0 62
ian@0 63
ian@0 64 Lookup algorithm
ian@0 65 ----------------
ian@0 66
ian@0 67 We scan rules list, and if a rule is matched, apply it.
ian@0 68 If a route is found, return it.
ian@0 69 If it is not found or a THROW node was matched, continue
ian@0 70 to scan rules.
ian@0 71
ian@0 72 Applications
ian@0 73 ------------
ian@0 74
ian@0 75 1. Just ignore classes. All the routes are put into MAIN class
ian@0 76 (and/or into DEFAULT class).
ian@0 77
ian@0 78 HOWTO: iproute add PREFIX [ tos TOS ] [ gw GW ] [ dev DEV ]
ian@0 79 [ metric METRIC ] [ reject ] ... (look at iproute utility)
ian@0 80
ian@0 81 or use route utility from current net-tools.
ian@0 82
ian@0 83 2. Opposite case. Just forget all that you know about routing
ian@0 84 tables. Every rule is supplied with its own gateway, device
ian@0 85 info. record. This approach is not appropriate for automated
ian@0 86 route maintenance, but it is ideal for manual configuration.
ian@0 87
ian@0 88 HOWTO: iproute addrule [ from PREFIX ] [ to PREFIX ] [ tos TOS ]
ian@0 89 [ dev INPUTDEV] [ pref PREFERENCE ] route [ gw GATEWAY ]
ian@0 90 [ dev OUTDEV ] .....
ian@0 91
ian@0 92 Warning: As of now the size of the routing table in this
ian@0 93 approach is limited to 256. If someone likes this model, I'll
ian@0 94 relax this limitation.
ian@0 95
ian@0 96 3. OSPF classes (see RFC1583, RFC1812 E.3.3)
ian@0 97 Very clean, stable and robust algorithm for OSPF routing
ian@0 98 domains. Unfortunately, it is not widely used in the Internet.
ian@0 99
ian@0 100 Proposed setup:
ian@0 101 255 local addresses
ian@0 102 254 interface routes
ian@0 103 253 ASE routes with external metric
ian@0 104 252 ASE routes with internal metric
ian@0 105 251 inter-area routes
ian@0 106 250 intra-area routes for 1st area
ian@0 107 249 intra-area routes for 2nd area
ian@0 108 etc.
ian@0 109
ian@0 110 Rules:
ian@0 111 iproute addrule class 253
ian@0 112 iproute addrule class 252
ian@0 113 iproute addrule class 251
ian@0 114 iproute addrule to a-prefix-for-1st-area class 250
ian@0 115 iproute addrule to another-prefix-for-1st-area class 250
ian@0 116 ...
ian@0 117 iproute addrule to a-prefix-for-2nd-area class 249
ian@0 118 ...
ian@0 119
ian@0 120 Area classes must be terminated with reject record.
ian@0 121 iproute add default reject class 250
ian@0 122 iproute add default reject class 249
ian@0 123 ...
ian@0 124
ian@0 125 4. The Variant Router Requirements Algorithm (RFC1812 E.3.2)
ian@0 126 Create 16 classes for different TOS values.
ian@0 127 It is a funny, but pretty useless algorithm.
ian@0 128 I listed it just to show the power of new routing code.
ian@0 129
ian@0 130 5. All the variety of combinations......
ian@0 131
ian@0 132
ian@0 133 GATED
ian@0 134 -----
ian@0 135
ian@0 136 Gated does not understand classes, but it will work
ian@0 137 happily in MAIN+DEFAULT. All policy routes can be set
ian@0 138 and maintained manually.
ian@0 139
ian@0 141 --------------
ian@0 142 route.c has a compilation time switch CONFIG_IP_LOCAL_RT_POLICY.
ian@0 143 If it is set, locally originated packets are routed
ian@0 144 using all the policy list. This is not very convenient and
ian@0 145 pretty ambiguous when used with NAT and masquerading.
ian@0 146 I set it to FALSE by default.
ian@0 147
ian@0 148
ian@0 149 Alexey Kuznetov
ian@0 150 kuznet@ms2.inr.ac.ru