summaryrefslogtreecommitdiff
path: root/net/dccp/ccids/Kconfig
blob: 8ba3fc9d6d168f33deecb17a61b62e84353993ab (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
menu "DCCP CCIDs Configuration"

config IP_DCCP_CCID2_DEBUG
	bool "CCID-2 debugging messages"
	---help---
	  Enable CCID-2 specific debugging messages.

	  The debugging output can additionally be toggled by setting the
	  ccid2_debug parameter to 0 or 1.

	  If in doubt, say N.

config IP_DCCP_CCID3
	bool "CCID-3 (TCP-Friendly)"
	def_bool y if (IP_DCCP = y || IP_DCCP = m)
	---help---
	  CCID-3 denotes TCP-Friendly Rate Control (TFRC), an equation-based
	  rate-controlled congestion control mechanism.  TFRC is designed to
	  be reasonably fair when competing for bandwidth with TCP-like flows,
	  where a flow is "reasonably fair" if its sending rate is generally
	  within a factor of two of the sending rate of a TCP flow under the
	  same conditions.  However, TFRC has a much lower variation of
	  throughput over time compared with TCP, which makes CCID-3 more
	  suitable than CCID-2 for applications such streaming media where a
	  relatively smooth sending rate is of importance.

	  CCID-3 is further described in RFC 4342,
	  http://www.ietf.org/rfc/rfc4342.txt

	  The TFRC congestion control algorithms were initially described in
	  RFC 5348.

	  This text was extracted from RFC 4340 (sec. 10.2),
	  http://www.ietf.org/rfc/rfc4340.txt

	  If in doubt, say N.

config IP_DCCP_CCID3_DEBUG
	bool "CCID-3 debugging messages"
	depends on IP_DCCP_CCID3
	---help---
	  Enable CCID-3 specific debugging messages.

	  The debugging output can additionally be toggled by setting the
	  ccid3_debug parameter to 0 or 1.

	  If in doubt, say N.

config IP_DCCP_TFRC_LIB
	def_bool y if IP_DCCP_CCID3

config IP_DCCP_TFRC_DEBUG
	def_bool y if IP_DCCP_CCID3_DEBUG
endmenu
n extension to the core code for dynamically allocating states in the prepare stage. The extension is necessary right now because we need a proper way to unbreak LTTNG, which iscurrently non functional due to the removal of the notifiers. Surely it's out of tree, but it's widely used by distros. The simple solution would have been to reserve a state for LTTNG, but I'm not fond about unused crap in the kernel and the dynamic range, which we admittedly should have done right away, allows us to remove quite some of the hardcoded states, i.e. those which have no ordering requirements. So doing the right thing now is better than having an smaller intermediate solution which needs to be reworked anyway" * 'smp-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: cpu/hotplug: Provide dynamic range for prepare stage perf/x86/amd/ibs: Fix typo after cleanup state names in cpu/hotplug
Diffstat (limited to 'tools/perf/Documentation/intel-pt.txt')