09 Oct, 2005
1 commit
-
- added typedef unsigned int __nocast gfp_t;
- replaced __nocast uses for gfp flags with gfp_t - it gives exactly
the same warnings as far as sparse is concerned, doesn't change
generated code (from gcc point of view we replaced unsigned int with
typedef) and documents what's going on far better.Signed-off-by: Al Viro
Signed-off-by: Linus Torvalds
18 Sep, 2005
2 commits
-
Allocation for the optnames is similar to the DCCP options, with a
range for rx and tx half connection CCIDs.Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
Moving the TFRC sender and receiver variables to separate structs, so
that we can copy these structs to userspace thru getsockopt,
dccp_diag, etc.Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller
13 Sep, 2005
1 commit
-
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller
10 Sep, 2005
2 commits
-
Also use some BUG_ON where appropriate and use LIMIT_NETDEBUG for the unlikely
cases where we, at this stage, want to know about, that in my tests hasn't
appeared in the radar.Signed-off-by: Arnaldo Carvalho de Melo
-
To match more closely what is described in RFC 3448.
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Ian McDonald
09 Sep, 2005
8 commits
-
Signed-off-by: Arnaldo Carvalho de Melo
-
To start the timestamps with 0.0ms, easing the integer maths in the CCIDs, this
probably will be reworked to use the to be introduced struct timeval_offset
infrastructure out of skb_get_timestamp, etc.Signed-off-by: Arnaldo Carvalho de Melo
-
The initialization of ccid3hcrx_rtt to 5ms is just a bandaid, I'll continue
auditing the CCID3 HC rx codebase to fix this properly, probably I'll add a
feedback timer as suggested in the CCID3 draft.Signed-off-by: Arnaldo Carvalho de Melo
-
Signed-off-by: Arnaldo Carvalho de Melo
-
Signed-off-by: Arnaldo Carvalho de Melo
-
Signed-off-by: Arnaldo Carvalho de Melo
-
Signed-off-by: Arnaldo Carvalho de Melo
-
Signed-off-by: Arnaldo Carvalho de Melo
30 Aug, 2005
26 commits
-
This makes the send rate calculations behave way more closely to what
is specified, with the jitter previously seen on x and x_recv
disappearing completely on non lossy setups.This resembles the tcp_data_snd_check code, that possibly we'll end up
using in DCCP as well, perhaps moving this code to
inet_connection_sock.For now I'm doing the simplest implementation tho.
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
So that applications can set dccp_sock->dccps_pkt_size, that in turn
is used in the CCID3 half connection init routines to set
ccid3hc[tr]x_s and use it in its rate calculations.Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
Renaming it to dccp_rx_hist_detect_loss.
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
Renaming it to dccp_rx_hist_add_packet.
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
I'll now take a look at the other proposed TFRC DCCP CCIDs to find
more code that is now in ccid3.c and move to this module, the loss
event rate, calc_X, etc most probably will be moved there.The main goal of these changes is to pave the way for the
implementation of more TFRC based DCCP CCIDs and to shrink ccid3.c,
reducing its complexity and helping in getting it rock solid.Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
And put this into net/dccp/ccids/lib/, where packet_history.[ch] will also be
moved and then we'll have a tfrc_lib.ko module that will be used by
dccp_ccid3.ko and other CCIDs that are variations of TFRC (RFC 3448).Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
To avoid open coding this all over the place.
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
Introducing functions to add to or subtract from a timeval variable
and renaming now_delta to timeval_new_delta that calls do_gettimeofday
and then timeval_delta, that should be used when there are several
deltas made relative to the current time or setting variables to it,
so as to avoid calling do_gettimeofday excessively.I'm leaving these "timeval_" prefixed funcions internal to DCCP for a
while till we're sure there are no subtle bugs in it.It also is more correct as it checks if the number of usecs added to
or subtracted from a tv_usec field is more than 2 seconds.Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
No code changes.
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
This is not quite what I think we should have long term but improves
performance for now, so lets use it till we get CCID3 working well,
then we can think about using sk_write_queue, perhaps using some ideas
from Juwen Lai's old stack for 2.4.20.Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
This patch puts mostly read only data in the right section
(read_mostly), to help sharing of these data between CPUS without
memory ping pongs.On one of my production machine, tcp_statistics was sitting in a
heavily modified cache line, so *every* SNMP update had to force a
reload.Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller -
And also hc_tx and hc_rx get_info functions for the CCIDs to fill in
information that is specific to them.For now reusing struct tcp_info, later I'll try to figure out a better
solution, for now its really nice to get this kind of info:[root@qemu ~]# ./ss -danemi
State Recv-Q Send-Q Local Addr:Port Peer Addr:Port
LISTEN 0 0 *:5001 *:* ino:628 sk:c1340040
mem:(r0,w0,f0,t0) cwnd:0 ssthresh:0
ESTAB 0 0 172.20.0.2:5001 172.20.0.1:32785 ino:629 sk:c13409a0
mem:(r0,w0,f0,t0) ts rto:1000 rtt:0.004/0 cwnd:0 ssthresh:0 rcv_rtt:61.377This, for instance, shows that we're not congestion controlling ACKs,
as the above output is in the ttcp receiving host, and ttcp is a one
way app, i.e. the received never calls sendmsg, so
ccid_hc_tx_send_packet is never called, so the TX half connection
stays in TFRC_SSTATE_NO_SENT state and hctx_rtt is never calculated,
stays with the value set in ccid3_hc_tx_init, 4us, as show above in
milliseconds (0.004ms), upcoming patches will fix this.rcv_rtt seems sane tho, matching ping results :-)
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
Using TIMESTAMP_ECHO and ELAPSED_TIME options received.
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
CCID3 keeps this variable in usecs, inet_connection_socks in jiffies,
so to avoid Mars orbiter losses lets reintroduce ccid3hctx_t_rto 8)Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
This changes timestamp, timestamp echo, and elapsed time to use units of 10
usecs as per DCCP spec. This has been tested to verify that times are correct.
Also fixed up length and used hton/ntoh more.Still to add in later patches:
- actually use elapsed time to adjust RTT
(commented out as was prior to this patch)
- send options at times more closely following the spec
(content is now correct)Signed-off-by: Ian McDonald
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
may be a false warning if there always is something on ccid3hcrx_hist:
net/dccp/ccids/ccid3.c: In function 'ccid3_hc_rx_packet_recv':
net/dccp/ccids/ccid3.c:1634: warning: 'tstamp.tv_usec' may be used uninitialized in this function
net/dccp/ccids/ccid3.c:1634: warning: 'tstamp.tv_sec' may be used uninitialized in this functionconst on inline functions doesn't have any effect:
net/dccp/dccp.h:64: warning: type qualifiers ignored on function return type
net/dccp/dccp.h:70: warning: type qualifiers ignored on function return type
net/dccp/dccp.h:76: warning: type qualifiers ignored on function return typeSigned-off-by: Patrick McHardy
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
Only available if CONFIG_DEBUG_KERNEL is enabled in the "Kernel
Hacking" Menu.Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
As requested by Ian.
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Ian McDonald
Signed-off-by: David S. Miller -
That is equivalent, no need to have a private one.
Signed-off-by: Arnaldo Carvalho de Melo
-
This also changes the list_for_each_entry_safe_continue behaviour to match its
kerneldoc comment, that is, to start after the pos passed.Also adds several helper functions from previously open coded fragments, making
the code more clear.Signed-off-by: Arnaldo Carvalho de Melo
-
This way it gets closer to the TCP flow, where congestion window
checks are done, it seems we can map ccid_hc_tx_send_packet in
dccp_write_xmit to tcp_snd_wnd_test in tcp_write_xmit, a CCID2
decision should just fit in here as well...Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller
