- 26 Apr, 2007 40 commits
-
-
Thomas Graf authored
Signed-off-by:
Thomas Graf <tgraf@suug.ch> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Thomas Graf authored
Signed-off-by:
-
Thomas Graf authored
Signed-off-by:
-
Thomas Graf authored
Signed-off-by:
Steven Whitehouse <swhiteho@redhat.com> Signed-off-by:
-
Thomas Graf authored
Signed-off-by:
-
Thomas Graf authored
Signed-off-by:
-
Thomas Graf authored
Signed-off-by:
-
Thomas Graf authored
Signed-off-by:
-
Thomas Graf authored
Signed-off-by:
-
Thomas Graf authored
Signed-off-by:
-
Thomas Graf authored
Signed-off-by:
-
Thomas Graf authored
This patch adds a new interface to register rtnetlink message handlers replacing the exported rtnl_links[] array which required many message handlers to be exported unnecessarly. Signed-off-by:
-
Gerrit Renker authored
The patch follows the following recommendation made in an erratum to RFC 4342: "Senders MAY additionally make use of other available RTT measurements, including those from the initial Request-Response packet exchange." It implements larger initial windows with regard to this inital RTT measurement, using the mechanism suggested in draft-ietf-dccp-rfc3448bis, section 4.2. Signed-off-by:
Gerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by:
Ian McDonald <ian.mcdonald@jandi.co.nz> Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Gerrit Renker authored
Function:
-
Gerrit Renker authored
This replaces the existing occurrences of RTT sampling with the use of the new function dccp_sample_rtt. Signed-off-by:
-
Gerrit Renker authored
A recurring problem, in particular in the CCID code, is that RTT samples from packets with timestamp echo and elapsed time options need to be taken. This service is provided via a new function dccp_sample_rtt in this patch. Furthermore, to protect against `insane' RTT samples, the sampled value is bounded between 100 microseconds and 4 seconds - for which u32 is sufficient. Signed-off-by:
-
Gerrit Renker authored
This updates the code with regard to handling idle and application-limited periods as specified in [RFC 4342, 5.1]. Background:
-
Gerrit Renker authored
The CCID 3 and TFRC specs (RFC 4342, RFC 3448, draft-3448bis) make frequent reference to the computation of the RFC-3390 initial sending rate: 1. Initial sending rate when RTT is known (RFC 4342, p. 6) 2. Response to Idle/Application-Limited periods (RFC 4342, 5.1) This warrants putting the code into its own function, for later code reuse. Signed-off-by:
-
Gerrit Renker authored
This clears the following sparc64 build warnings: 1) warning: format "%ld" expects type "long int", but argument 3 has type "suseconds_t" 2) warning: format "%llu" expects type "long long unsigned int", but argument 3 has type "__u64" Fixed by using typecast to unsigned. This is argued to be safe, since the quantities, after de-scaling (factor 2^6) fit all in u32. Signed-off-by:
-
Gerrit Renker authored
This adds a few more fields of interest to /proc/net/dccpprobe, the following output ensues: 1 2 3 4 5 6 7 8 9 10 11 sec.usec src:sport dst:dport size s rtt p X_calc X_recv X t_ipi Also made the formatting consistent. Scripts that go with this can be downloaded from http://139.133.210.30/users/gerrit/dccp/dccp_probe/Signed-off-by:
-
Gerrit Renker authored
This updates the documentation on CCID3-specific options. Signed-off-by:
-
Gerrit Renker authored
This adds more detail in the wait_for_ccid packet scheduling loop. In particular, it informs about (i) when delay is used and (ii) why a packet is discarded. Signed-off-by:
-
Gerrit Renker authored
Currently debugging output (when configured) is automatically enabled when DCCP modules are compiled into the kernel rather than built as loadable modules. This is not necessary, since the module parameters in this case become kernel commandline parameters, e.g. DCCP or CCID3 debug output can be enabled for a static build by appending the following at the boot prompt: dccp.dccp_debug=1 dccp_ccid3.ccid3_debug=1 This patch therefore does away with the more complicated way of always enabling debug output for static builds Signed-off-by:
-
Gerrit Renker authored
This: 1. removes a race condition in the access to the scheduled send time t_nom which results from allowing asynchronous r/w access to t_nom without locks; 2. updates the inter-packet interval t_ipi = s/X when `s' changes, following a suggestion by Ian McDonald. Signed-off-by: -
Ian McDonald authored
This adds a few debugging statements to ccid3.c Signed-off-by:
-
Ian McDonald authored
This fixes a bug which uses an invalid comparison. The bug resulted in the use of invalid loss intervals. Signed-off-by:
-
Gerrit Renker authored
This improves the slow-start phase by using the MSS (as suggested in RFC 4342, sec. 5) instead of the packet size s. Also figured out that __u32 is ample resource enough. After applying, I got the following in the logs: ccid3_hc_tx_packet_recv: client(f7421700), s=6, MSS=1424, w_init=4380, R_sample=176us, X=24886363 Had the previous variant been used, w_init would have been as low as 24. Committer note: removed unneeded cast to unsigned long long that was causing a compiler warning on 64bit architectures. Signed-off-by: -
Gerrit Renker authored
No code change at all. This splits ccid3.c into a RX and a TX section, so that the file has an organisation similar to the other ones (e.g. packet_history.{h,c}). Signed-off-by: -
Gerrit Renker authored
Since CCID3 avoids sending 0-byte data packets (cf. ccid3_hc_tx_send_packet), testing for zero-payload length, as performed by ccid3_hc_tx_update_s, is redundant - hence removed by this patch. Signed-off-by:
-
Gerrit Renker authored
This removes two ambiguities in employing the new definition of before48, following the analysis on http://www.mail-archive.com/dccp@vger.kernel.org/msg01295.html (1) Updating GSR when P.seqno >= S.SWL With the old definition we did not update when P.seqno and S.SWL are 2^47 apart. To ensure the same behaviour as with the old definition, this is replaced with the equivalent condition dccp_delta_seqno(S.SWL, P.seqno) >= 0 (2) Sending SYNC when P.seqno >= S.OSR Here it is debatable whether the new definition causes an ambiguity: the case is similar to (1); and to have consistency with the case (1), we use the equivalent condition dccp_delta_seqno(S.OSR, P.seqno) >= 0 Detailed Justification
-
Gerrit Renker authored
The follows48 relation identifies whether 48-bit sequence number x is the direct successor of y. Currently, it does not handle cases of the following type correctly: follows48(0x(prefix)10000LL, 0x(prefix)0FFFFLL) where prefix is an arbitrary hex sequence of up to 7 digits. This is fixed by reusing the new dccp_delta_seqno function. Signed-off-by:
-
Gerrit Renker authored
Problem:
-
Gerrit Renker authored
Problem:
-
Gerrit Renker authored
This patch * organizes the sequence arithmetic functions into one corner of dccp.h * performs a small modification of dccp_set_seqno to make it more widely reusable (now it is safe to use any number, since it performs modulo-2^48 assignment) * adds functions and generic macros for 48-bit sequence arithmetic: --48 bit complement --modulo-48 addition and modulo-48 subtraction --dccp_inc_seqno now a special case of add48 Constants renamed following a suggestion by Arnaldo. Signed-off-by:
-
Arnaldo Carvalho de Melo authored
Reducing the number of skb->data direct accesses. Signed-off-by:
-
Arnaldo Carvalho de Melo authored
At that point it is equivalent to what was being used, skb->end - skb->data, and the need is clearly the one skb_tailroom satisfies. Signed-off-by:
-
Arnaldo Carvalho de Melo authored
Signed-off-by: -
Arnaldo Carvalho de Melo authored
So that we reduce the number of direct accesses to skb->data. Signed-off-by: -
Arnaldo Carvalho de Melo authored
Signed-off-by:
-
Arnaldo Carvalho de Melo authored
Not used anywhere and defined inside __KERNEL__, Thomas acked this on irc. Signed-off-by:
-
