This is a resubmission to fix a problem with accounting for Ack Vector
length in the MPS.
The present solution did not work well: the MPS did not account for Ack Vectors,
so that applications which relied on the MPS value via getopt were
disadvantaged
by having all their Ack Vectors put onto
to define a corresponding CCID field.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
Acked-by: Ian McDonald [EMAIL PROTECTED]
---
net/dccp/ackvec.h |3 +++
net/dccp/output.c | 22 ++
2 files changed, 17 insertions(+), 8 deletions(-)
--- a/net/dccp/ackvec.h
+++ b/net/dccp
This is a re-packaged resubmission (reduction from about 20 small patches) of
the
Ack Vector patch set, which accomplishes two main things.
First, it completes the implementation of a circular Ack Vector buffer. So far
the buffer was implemented as a linear array which dropped packets on
at the beginning of the connection this can be very counter-
intuitive and annoying.
(Over the long term there should be some adjustment to reduce MPS at least
by a minimum when Ack Vectors are used; some applications may rely on the
exact value of the MPS).
Signed-off-by: Gerrit Renker [EMAIL PROTECTED
()) is therefore removed.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ackvec.c | 88
net/dccp/ackvec.h |6 +++
net/dccp/input.c |4 +-
net/dccp/options.c | 12 ++-
4 files changed, 100 insertions(+), 10 deletions
).
Hence the patch uses a different policy: when the buffer overflows, the oldest
entries are subsequently overwritten. This has a higher chance of recovery.
Details are on http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/ack_vectors/
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp
code
to fetch parsed Ack Vectors via this interface;
* a data structure, `struct dccp_ackvec_parsed' is provided as interface;
* this structure arranges Ack Vectors of the same skb into a FIFO order;
* a doubly-linked list is used to keep the required FIFO code small.
Signed-off-by: Gerrit
.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/Kconfig |3 -
net/dccp/Makefile |5 +-
net/dccp/ackvec.c | 252
net/dccp/ackvec.h | 79 +---
net/dccp/ccids/Kconfig |1 -
5 files changed
This set of patches extends the packet sending/dequeuing interface, which is
currently restricted to using time intervals only. This forces CCID-2 into
a constant polling mode, which is removed in patch #4.
Patch #1: Extends the CCID packet dequeuing interface to allow CCIDs to
end (compare
with call to tcp_write_queue_purge in tcp_disconnect()).
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/proto.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -277,7 +277,9 @@ int dccp_disconnect(struct sock *sk
time),
(c) wait-for-ccid could not finish within the given time limit.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/dccp.h |3 +-
net/dccp/output.c | 122 ++---
net/dccp/proto.c | 15 ++-
net/dccp/timer.c |2 +-
4
.
If the tasklet finds that the socket is locked, it re-schedules the tasklet
function (not the tasklet) after one jiffy.
Changed DCCP_BUG to DCCP_WARN when transmit_skb returns an error (e.g. when a
local qdisc is used, NET_XMIT_DROP=1 can be returned for many packets).
Signed-off-by: Gerrit Renker [EMAIL
| The killer is the large buffering - do you know what size the Linksys
| has? Also what size transmit buffer and what size sequence validation
| window did you use. If these two were reduced then you might stop the
| buffering occurring elsewhere...
|
For socket buffer sizes I used the default
I have uploaded an annotated set of plots on CCID3 over WiFi on
http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/ccid3/ccid3_over_wifi/
The interest was to get away from emulated networks. The WiFi link provides
a real-world scenario which will create loss (100Mbs feeding into 11Mbps).
Note:
of the initial loss interval, and thus unnecessarily reducing the throughput.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/lib/tfrc_equation.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--- a/net/dccp/ccids/lib/tfrc_equation.c
+++ b/net/dccp/ccids/lib
Step 8.5 in RFC 4340 says for the newly cloned socket
Initialize S.GAR := S.ISS,
but what in fact the code (minisocks.c) does is
Initialize S.GAR := S.ISR,
which is wrong (typo?) -- fixed by the patch.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp
This is a set of bug fixes for CCID3 and general DCCP.
Please consider patches #1, #2, #3. The remainder are for the test tree
(but are fixes nonetheless) and may not apply directly onto mainline; with
regard to patch #6, please see note at end of message.
Patch #1: Fixes a CCID3 bug: when loss
, AWH := GSS
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/dccp.h | 20
net/dccp/input.c | 18 ++
net/dccp/minisocks.c | 30 +-
3 files changed, 35 insertions(+), 33 deletions(-)
--- a/net/dccp/dccp.h
| So maybe the cause triggering this oops is somewhere else.
|
| yes, probably. sorry - i didn`t tell or maybe i didn`t know when writing
| my first mail to module authors and forget to add that before forwarding here.
|
| for me , the problem does not happen with suse kernel of the day
|
Roland, -
apparently, i got crashes when loading/unloading other driver modules just
after ccid2 or ccid3 had been loaded/unloaded _once_ (have not used them at
all, just modprobe module;modprobe -r module)
snip
the easiest way to reproduce is:
while true;do modprobe
| the easiest way to reproduce is:
|
| while true;do modprobe dccp_ccid2/3;modprobe -r dccp_ccid2/3;done
| after short time, the kernel oopses (messages below)
|
snip
|
| Gerrit, the control socket isn't attached to any CCID module, so the
| CCID modules should be safe to remove, and
This is patch 2 in the set and uses the routines provided by the previous
patch to implement parsing of received Ack Vectors, replacing duplicate code.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid2.c | 132
net/dccp
this can be very counter-
intuitive and annoying.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
include/linux/dccp.h |2 ++
net/dccp/options.c | 28 +++-
net/dccp/output.c|8
3 files changed, 29 insertions(+), 9 deletions(-)
--- a/include/linux
' is provided, which arranges all
Ack Vectors of a single skb into a list of parsed chunks;
* a doubly-linked list was used since insertion needs to be at the tail end;
* the associated list handling and list de-allocation routines.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp
This is the new stuff for Ack Vectors, completing the Ack Vector work.
All other patches are as before, with the single exception of the update sent
yesterday (the recovery strategy for dealing with suddenly large losses).
Arnaldo, can you please indicate whether I should resubmit the older
Quoting Tomasz Grobelny:
| As http://www.erg.abdn.ac.uk/ seems to be down at least since yesterday I'd
| like to ask whether any mirror of dccp git tree and/or dccp patches to
| mainline kernel is available. TIA,
| --
Sorry about the outage, our building was renovated over the holidays. I
am
, Gerrit Renker [EMAIL PROTECTED]:
| And your naming scheme changed from version 1 to version 2:
|
| This is patch v2:
| | switch (optname) {
| | case DCCP_SOCKOPT_CCID_TX_INFO:
| | - if (len sizeof(hctx-tfrchctx_tfrc))
| | + if (len sizeof(hctx-ttx_tfrc
Quoting Tomasz Grobelny:
| On Friday 28 December 2007, I wrote:
| Dnia Wednesday 26 of December 2007, napisa?e?:
| What are the panics you are getting? It might be worth posting them to
| the list.
|
| Here is the screenshot I captured a few days ago. Details:
| - kernel-vanilla
This is an edited list of recent changes in the test tree
git://eden-feed.erg.abdn.ac.uk/dccp_exp
At the top of each block is the name of the patch, followed by a short
description of the change, and the actual (or abridged if obvious) inter-diff.
Some of these changes refer to
disabled by this patch.
Two more changes suggested itself:
* replaced magic numbers for CCID-specific options with symbolic constants;
* replaced local variables `idx' with computation in argument list.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
include/linux/dccp.h |6 --
net/dccp
by the function (also same name as in A.3 of RFC 4340);
* the variable `ackno' now becomes unused in options.c, and therefore
is now used for other (space-saving) purposes.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ackvec.c | 114
overwritten. This has a higher chance of recovery.
Details are on http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/ack_vectors/
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ackvec.c | 11 ++-
net/dccp/ackvec.h | 12
net/dccp/dccp.h| 14 +++---
net
This replaces 3 #defines with an enum containing all possible
Ack Vector states as per RFC 4340, 11.4. This helps to reduce
the length of several expressions.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ackvec.c |7 +++
net/dccp/ackvec.h | 10 ++
net
time field
in the Timestamp Echo option).
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ackvec.c | 11 ---
net/dccp/ackvec.h |3 ---
2 files changed, 0 insertions(+), 14 deletions(-)
--- a/net/dccp/ackvec.h
+++ b/net/dccp/ackvec.h
@@ -12,7 +12,6 @@
*/
#include
Ack Vector.
The fix is in parsing Ack Vectors on all packet types which are allowed to
carry an Ack Vector.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid2.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
--- a/net/dccp/ccids/ccid2.c
+++ b/net/dccp/ccids
the old
state first before entering new state;
* Ack Event handling happens mostly within the CCIDs, not the main DCCP module.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/input.c | 38 +++---
1 files changed, 11 insertions(+), 27 deletions
This set of patches adds functionality to the existing DCCP Ack Vector
implementation, extends it to a full circular buffer, and fixes two
previously undiscovered problems which otherwise result in a corrupted
buffer state.
It is important that Ack Vectors run reliably since otherwise problems in
of the last unacknowledged but received seqno in tail_ackno,
* has special cases to reset the overflow condition when appropriate,
* is protected against receiving older information (would mess up buffer
state).
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ackvec.c | 82
The length of the circular Ack Vector buffer is now determined dynamically,
as the span between head to tail.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ackvec.c | 21 +
net/dccp/ackvec.h |7 +++
net/dccp/options.c |7 ---
3 files changed
condition is
embedded in the loop condition of the subsequent list_for_each_entry_safe().
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ackvec.c | 78 +++--
1 files changed, 28 insertions(+), 50 deletions(-)
--- a/net/dccp/ackvec.c
This provides inlines for Ack Vector run length and state, which allow to wrap
several instances of the same code into function calls.
The unused function dccp_ackvec_print() (which also relied on the older
constants), has been removed.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net
-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ackvec.c | 107 +---
net/dccp/ackvec.h |5 +-
net/dccp/options.c | 65 +++
3 files changed, 85 insertions(+), 92 deletions(-)
--- a/net/dccp/ackvec.h
+++ b/net/dccp
[CCID3]: Whitespace cleanups and outdated documentation
This removes outdated documentation which had been forgotten to be
removed (x_recv, rtt now appear twice, p was removed from rx_sock);
and removes new whitespace.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid3.c
Both the dccp and the ccid4 trees have been brought up-to-date and uploaded.
Due to necessary building work, we have to power down almost all servers in
the department from
Friday 21st December 2007until
Sunday 6th January 2008
On Monday 7th January the server will be
| The end result should be equivalent, but please take a look and
That is a good catch - this patch was a pain to keep updated exactly due
to the many indentation levels. I had a quick look, the patch looks ok.
Just a small suggestion - since the RTT lookup code in tx_packet_recv()
is new,
| It was suggested that should email you regarding open source code for DCCP.
We are looking for open source code for DCCP for a master thesis which will
start in february. In particular we are looking for implementations that
support CCID4 and faster restart.
| Any help on this matter is
Burak
I have tried to replay your results but can not find anything wrong with the
current test kernel.
Please have a look at the results below, I repeated the same experiment on two
different testbeds.
Incidentally, these results agree with the values you observed for TCP Reno. It
seems that
| git-clone git://eden-feed.erg.abdn.ac.uk/dccp_exp my_dccp
|
|
| But I did not check out the DCCP sub-branch, by:
|
| git-checkout --track -b dccp origin/dccp
|
|
| However, as I type this command above, git complains saying:
|
| git checkout: branch dccp already exists
|
|
|
I've been working on making DCCP Ack Vectors more robust, dealing more
gracefully
with buffer overflow, and fixing two cases which will lead to corrupted buffer
state.
The encountered problems and implementation strategy are documented on
| This time around I'm not doing any reordering, just trying to use your
| patches as is, but adding this patch as-is produces a kernel that will
| crash, no?
|
| The loss history and the RX/TX packet history slabs are all created in
| tfrc.c using the three different __init routines of the
| +static struct kmem_cache *tfrc_lh_slab __read_mostly;/* === */
|
| Yup, this one, is introduced as above but is not initialized at the
| module init routine, please see, it should be OK and we can move on:
|
|
| When interfacing we must make sure that ccid3 tfrc_lh_slab is created
| and then tfrc_li_cachep is not needed. I'm doing this while keeping
| the structure of the patches, i.e. one introducing, the other removing.
| But we need to create tfrc_lh_slab if we want the tree to be bisectable.
|
|
This is to announce that the CCID4 tree at
git://eden-feed.erg.abdn.ac.uk/dccp_exp [ccid4]
has been updated with regard to the latest changes on the list.
It compiles cleanly, also did some application-level testing
(streaming).
-
To unsubscribe from this list: send the line
| I am new of this mailing list and I am really interested in the
| measurements you are performing with DCCP.
This was more of a regression test, as there had been recent changes in
the test tree, to see that the kernel (not userspace) still performs in
a predictable way.
| Which tool are you
| This separates RX/TX initialisation and puts all packet history / loss
intervals
| initialisation into tfrc.c.
| The organisation is uniform: slab declaration - {rx,tx}_init() -
{rx,tx}_exit()
|
| NAK, you can't call a __exit marked routine from a __init marked
| routine.
|
Ok thanks,
|
|distcc[24516] ERROR: compile
/root/.ccache/packet_his.tmp.aspire.home.net.24512.i on _tiptop failed
|/usr/src/davem-2.6/net/dccp/ccids/lib/packet_history.c: In function
'__one_after_loss':
|/usr/src/davem-2.6/net/dccp/ccids/lib/packet_history.c:266: error: lvalue
required as
(), which
in turn require the definition of the other inlines (macros).
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/lib/packet_history.c | 35 ---
net/dccp/ccids/lib/packet_history.h | 35 +++
2 files changed, 35
consistent.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid3.c |2 --
net/dccp/ccids/ccid3.h |4 ++--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/dccp/ccids/ccid3.c b/net/dccp/ccids/ccid3.c
index 60fcb31..b92069b 100644
--- a/net/dccp/ccids/ccid3.c
As promised, here are some test results using the latest (2.6.25-backported)
version of the test tree.
These are sanity checks and by no means statistically significant. For
that it would necessary to run more tests, take averages and calculate
standard deviation / error bars.
Longer test runs (
did.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/lib/packet_history.c | 35 ---
1 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/net/dccp/ccids/lib/packet_history.c
b/net/dccp/ccids/lib/packet_history.c
index 4d37396..6256bec
/
fallback RTT value (defined in section 3.4 of RFC 4340 as 0.2 sec); while
at it, the upper bound of 4 seconds for an RTT sample has been reduced to
match the initial TCP RTO value of 3 seconds from[RFC 1122, 4.2.3.1].
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
Signed-off-by: Ian McDonald [EMAIL
/packet_history.c:337: error: lvalue
required as unary '' operand
make[4]: *** [net/dccp/ccids/lib/packet_history.o] Error 1
make[3]: *** [net/dccp/ccids/lib] Error 2
make[2]: *** [net/dccp/ccids] Error 2
make[1]: *** [net/dccp/] Error 2
make: *** [sub-make] Error 2
Signed-off-by: Gerrit Renker [EMAIL
This separates RX/TX initialisation and puts all packet history / loss intervals
initialisation into tfrc.c.
The organisation is uniform: slab declaration - {rx,tx}_init() -
{rx,tx}_exit()
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/lib/packet_history.c | 68
Just some tidy-ups to keep git/quilt happy. Also moved up the
comment Receiver routines above the first occurrence of RX
history routines.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid3.c | 16
net/dccp/ccids/lib/loss_interval.c |2
This moves two inlines back to packet_history.h: these are not private
to packet_history.c, but are needed by CCID3/4 to detect whether a new
loss is indicated, or whether a loss is already pending.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/lib/packet_history.c | 26
-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid3.c |3 +--
net/dccp/ccids/lib/packet_history.c |5 -
2 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/net/dccp/ccids/ccid3.c b/net/dccp/ccids/ccid3.c
index a5246f7..60fcb31 100644
--- a/net/dccp
for NDUPACK=3 packets to fill the hole;
- updating loss records when a late-arriving packet fills a hole.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
Signed-off-by: Ian McDonald [EMAIL PROTECTED]
---
net/dccp/ccids/lib/loss_interval.c | 158 ++-
net/dccp/ccids/lib
Some of the recent changes in 2.6.25 cause problems with the existing
implementation (i.e. break
the code). This patch set therefore provides fixes and resubmits one subsequent
patch which
has not been considered so far, but which is part of the tfrc_lib package.
Patch #1: Performs whitespace
Below are some test results with the latest CCID4 subtree; two tests were
performed:
(a) iperf throughput tests
(b) audio streaming using paraslash.
Both tests were performed using DCCPv6 only, so DCCPv4 supposedly works also.
1. iperf throughput testing
---
To make
| Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe dccp in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
| Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe dccp in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
| Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe dccp in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Today being Wednesday, below is some feedback after working through the patch
set.
Hope this is helpful.
Patch #1:
-
Several new good points are introduced:
- IP_DCCP_TFRC_DEBUG is made dependent on IP_DCCP_TFRC_DEBUG which is useful
- the select from CONFIG_IP_DCCP_CCID3 =
| @@ -788,8 +782,8 @@ static void ccid3_hc_rx_packet_recv(stru
| if (unlikely(hcrx-ccid3hcrx_state == TFRC_RSTATE_NO_DATA)) {
| if (is_data_packet) {
| do_feedback = FBACK_INITIAL;
| + hcrx-ccid3hcrx_s = payload_size;
|
| Patch #3:
| -
|Renames s/tfrc_tx_hist/tfrc_tx_hist_slab/g; no problems.
|
| This was for consistency with the other slabs in DCCP:
|
| [EMAIL PROTECTED] net-2.6.25]$ find net/dccp/ -name *.c | xargs grep
'struct kmem_cache'
Thanks, I will put the same naming scheme also in the
| Thanks, I folded this into the reorganized RX history handling patch,
| together with reverting ccid3_hc_rx_packet_recv to very close to your
| original patch, with this changes:
|
| 1. no need to calculate the payload size for non data packets as this
|value won't be used.
| 2. Initialize
| In the end this went back to the same questions and issues that were
tackled between
| February and March this year. I wish we could have had this dicussion then;
it would
| have made this email unnecessary.
|
| That is why it is important that the changeset comment collects these
|
| I found a problem that I'm still investigating if was introduced by this
| patch or if was already present. When sending 1 million 256 byte packets
| with ttcp over loopback, using ccid3 it is crashing, the test machine
| I'm using doesn't have a serial port, its a notebook, will switch to
|
Quoting Arnaldo:
| Em Tue, Dec 04, 2007 at 06:55:17AM +, Gerrit Renker escreveu:
| NAK. You have changed the control flow of the algorithm and the underlying
| data structure. Originally it had been an array of pointers, and this had
| been a design decision right from the first submissions
tfrc_module source file (this is later populated
with TX/RX hist and LI Database routines);
(2) a dedicated tfrc_pr_debug macro with toggle switch `tfrc_debug'.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
Signed-off-by: Ian McDonald [EMAIL PROTECTED]
---
net/dccp/ccids/Kconfig
out by
Arnaldo);
* no other code calls this function, hence the inline function can go.
Also replaced the first call to updating s with direct assignment of
`payload_size'; this has also
been pointed out by Arnaldo.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid3.c
Orthogonal to the ongoing discussion of patches, here are updates
of existing ones. This is mainly to keep the test tree in synch;
I'd like to upload the new test tree since -rc4 is out.
Arnaldo has actually pointed out more bugs than I have given him credit for,
these are contained in this patch
I have now updated the CCID4 subtree with regard to the latest changes in the
CCID3 module:
* rx_update_s() becomes obsolete
* instead, the `s' value is set to payload_size (first packet) or
* set to tfrc_ewma() (all further data packets).
Furthermore (and this has been updated for CCID3 also)
-by: Gerrit Renker [EMAIL PROTECTED]
Signed-off-by: Ian McDonald [EMAIL PROTECTED]
---
net/dccp/ccids/ccid3.c | 292 ++--
net/dccp/ccids/ccid3.h | 38 ---
2 files changed, 102 insertions(+), 228 deletions(-)
diff --git a/net/dccp/ccids/ccid3.c b/net/dccp
for NDUPACK=3 packets to fill the hole;
- updating loss records when a late-arriving packet fills a hole.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
Signed-off-by: Ian McDonald [EMAIL PROTECTED]
---
net/dccp/ccids/lib/loss_interval.c | 158 +-
net/dccp/ccids
| | static inline void ccid3_hc_rx_update_s(struct ccid3_hc_rx_sock
*hcrx, int len)
| | {
| | if (likely(len 0))/* don't update on empty
packets (e.g. ACKs) */
| | hcrx-ccid3hcrx_s =
tfrc_ewma(hcrx-ccid3hcrx_s, len, 9);
| |
Sorry I only got this email today and it is a busy day, too.
The changes look good and are in general a further improvement on the
code. I like the idea of hiding the internals of the list structure in
the source file.
I wonder if one could go one step further and also take the timestamp
| I wonder if one could go one step further and also take the timestamp
| directly when looking up the previous history sample, e.g.
|
snip
|
| I thought about that, but ccid3_hc_tx_packet_recv needs a timestamp some
| lines below, when we reuse the ktime_get_real call.
|
Oh, of course -
I have backported Arnaldo's changes to the test tree by inserting a
dummy patch; all the other patches have been updated relative to this.
The set of patches has been uploaded, it remains fully bisectable (just
verified).
Work with regard to the more recent changes will have to be done later.
This is the revised and tested patch for supporting passive-close. Testing
was impaired by a nasty bug (patch #1) which lead to the final Reset not
being sent. Once that had been fixed, things worked out very smoothly.
Other than that I think that the patch set has much benefited from the
not.
The fix is to use the AF-independent rebuild_header routine.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/output.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/dccp/output.c
+++ b/net/dccp/output.c
@@ -391,7 +391,7 @@ int dccp_send_reset(struct sock *sk, enu
().
The latter is necesssary since dccp_rcv_closereq() is also called from
__dccp_rcv_established().
This patch removes the duplicate test.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/input.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/net/dccp/input.c
+++ b/net/dccp
of this patch.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
include/linux/dccp.h | 56 +++
net/dccp/proto.c | 22 ++--
2 files changed, 51 insertions(+), 27 deletions(-)
--- a/include/linux/dccp.h
+++ b/include/linux/dccp.h
for such a connection: the socket still exists, but its state
indicates it is unusable.
Last, dccp_finish_passive_close sets either DCCP_CLOSED or DCCP_CLOSING =
TCP_CLOSING, so that
sk_stream_wait_close() will wait for the final Reset (which will trigger
CLOSING = CLOSED).
Signed-off-by: Gerrit
| Also did you test this code? The patch on which this is based has been
| subjected to some extensive regression-testing. I can't tell if it will
| perform as intended.
|
| I performed testing, not exhaustive as the code should be equivalent to
| what you had done, or can you find, from code
After further analysis, I think that the way passive-close was implemented
by the patches (using intermediate states) is the cleanest (and maybe the
simplest solution).
It would be nice if it worked with the present approach of just enqueueing
via dccp_fin, but several demands make a simple
- the fallback value specified in
RFC 4340, 3.4 is used.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/output.c | 13 -
net/dccp/proto.c | 18 --
2 files changed, 12 insertions(+), 19 deletions(-)
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -985,24
The situation is clearer now: the passive-close patches are redundant, but the
problem still exists. A description is below; the three passive-close patches
have been taken out of the test tree and the updated test tree has been
uploaded to
git://eden-feed.erg.abdn.ac.uk/dccp_exp
I
| --
| The patch set migrates TFRC TX history to a singly-linked list.
|
| The details are:
| * use of a consistent naming scheme (all TFRC functions now begin with
`tfrc_');
| * allocation and cleanup are taken
Arnaldo,
| [DCCP]: Basic support for passive-close
|
| What happens if we receive a second CloseReq or a second Close packet or
| if the server performed an active close?
|
Just to say I am still working on this. First, thanks a lot for pointing
out the bug. This forced me to look again at
1 - 100 of 722 matches
Mail list logo
