On Sat, 30 Jun 2018, Neal Cardwell wrote:
> As I mentioned, I ran your patch through all our team's TCP
> packetdrill tests, and it passes all of the tests. One of our tests
> needed updating, because if there is a non-SACK connection with a
> spurious RTO due to a delayed flight of ACKs then the
On Fri, 29 Jun 2018, Neal Cardwell wrote:
> On Fri, Jun 29, 2018 at 6:07 AM Ilpo Järvinen
> wrote:
> >
> > If SACK is not enabled and the first cumulative ACK after the RTO
> > retransmission covers more than the retransmitted skb, a spurious
> > FRTO undo will tri
, only new data will be transmitted (if available) and
the next retransmission can occur only after a new RTO which in case
of multiple losses (that are not for consecutive packets) requires
one RTO per loss to recover.
Signed-off-by: Ilpo Järvinen
---
net/ipv4/tcp_input.c | 9 +
1 file
On Wed, 28 Mar 2018, Yuchung Cheng wrote:
> On Wed, Mar 28, 2018 at 7:14 AM, Yuchung Cheng <ych...@google.com> wrote:
> >
> > On Wed, Mar 28, 2018 at 5:45 AM, Ilpo Järvinen
> > <ilpo.jarvi...@helsinki.fi> wrote:
> > > On Tue, 27 Mar 2018, Yuchung Chen
On Wed, 28 Mar 2018, Yuchung Cheng wrote:
> On Tue, Mar 13, 2018 at 3:25 AM, Ilpo Järvinen
> <ilpo.jarvi...@helsinki.fi> wrote:
> >
> > If SACK is not enabled and the first cumulative ACK after the RTO
> > retransmission covers more than the retransmitted
On Wed, 28 Mar 2018, Yuchung Cheng wrote:
> On Tue, Mar 13, 2018 at 3:25 AM, Ilpo Järvinen
> <ilpo.jarvi...@helsinki.fi> wrote:
> > When a cumulative ACK lands to high_seq at the end of loss
> > recovery and SACK is not enabled, the sender needs to avoid
> > f
On Tue, 27 Mar 2018, Yuchung Cheng wrote:
> On Tue, Mar 27, 2018 at 7:23 AM, Ilpo Järvinen
> <ilpo.jarvi...@helsinki.fi> wrote:
> > On Mon, 26 Mar 2018, Yuchung Cheng wrote:
> >
> >> On Tue, Mar 13, 2018 at 3:25 AM, Ilpo Järvinen
>
On Mon, 26 Mar 2018, Yuchung Cheng wrote:
> On Tue, Mar 13, 2018 at 3:25 AM, Ilpo Järvinen
> <ilpo.jarvi...@helsinki.fi> wrote:
> >
> > A miscalculation for the number of acknowledged packets occurs during
> > RTO recovery whenever SACK is not enabled and a cum
On Tue, 13 Mar 2018, Eric Dumazet wrote:
> On Tue, Mar 13, 2018 at 3:25 AM, Ilpo Järvinen
> <ilpo.jarvi...@helsinki.fi> wrote:
> > Here is a series of fixes to issues that occur when SACK is not
> > enabled for a TCP connection. These are not fixes to just some
> > r
not allow ACK
shrinking the window for duplicate ACKs (that was previously
even called "treason" but the old charmy message is gone now).
The advertized window can only shrink when also ack field
changes which will not be blocked by this change as it is not
duplicate ACK.
Signed-o
No functional changes. This change simplifies the next change
slightly.
Signed-off-by: Ilpo Järvinen <ilpo.jarvi...@helsinki.fi>
---
net/ipv4/tcp_input.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
(and potentially newly sent
data segments too if the cumulative ACK covers that far).
Signed-off-by: Ilpo Järvinen <ilpo.jarvi...@helsinki.fi>
---
net/ipv4/tcp_input.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_i
Here is a series of fixes to issues that occur when SACK is not
enabled for a TCP connection. These are not fixes to just some
remote corner cases of recovery but many/almost all recoveries
without SACK will be impacted by one (or even more than one) of
them. The sender-side changes (1-4) are not
around to
the tcp_packet_delayed makes this change look more involved than
it really is.
The additional checks done in this change only affect non-SACK
case, the SACK case remains the same.
Signed-off-by: Ilpo Järvinen <ilpo.jarvi...@helsinki.fi>
---
net/ipv4/tcp_
-off-by: Ilpo Järvinen <ilpo.jarvi...@helsinki.fi>
---
net/ipv4/tcp_input.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 4a26c09..c60745c 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3166,6 +3166,15 @@ stat
On Fri, 9 Mar 2018, David Miller wrote:
> From: Ilpo Järvinen <ilpo.jarvi...@helsinki.fi>
> Date: Fri, 9 Mar 2018 16:11:47 +0200 (EET)
>
> > Unfortunately I don't have now permission to publish the time-seq
> > graph about it but I've tried to improve the changelog m
On Fri, 9 Mar 2018, Sergei Shtylyov wrote:
> On 03/09/2018 05:10 PM, Ilpo Järvinen wrote:
>
> > @@ -3068,8 +3072,11 @@ static int tcp_clean_rtx_queue(struct sock *sk, u32
> > prior_fack,
> > - if (!after(scb->end_seq, tp->high_seq))
> >
On Fri, 9 Mar 2018, David Miller wrote:
> From: Ilpo Järvinen <ilpo.jarvi...@helsinki.fi>
> Date: Fri, 9 Mar 2018 16:11:47 +0200 (EET)
>
> > Unfortunately I don't have now permission to publish the time-seq
> > graph about it but I've tried to improve the changelog m
On Wed, 7 Mar 2018, Yuchung Cheng wrote:
> On Wed, Mar 7, 2018 at 12:19 PM, Neal Cardwell <ncardw...@google.com> wrote:
> >
> > On Wed, Mar 7, 2018 at 7:59 AM, Ilpo Järvinen <ilpo.jarvi...@helsinki.fi>
> > wrote:
> > > A bogus undo may/will trigger
(and potentially newly sent
data segments too if the cumulative ACK covers that far).
Signed-off-by: Ilpo Järvinen <ilpo.jarvi...@helsinki.fi>
---
net/ipv4/tcp_input.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/ne
not allow ACK
shrinking the window for duplicate ACKs (that was previously
even called "treason" but the old charmy message is gone now).
The advertized window can only shrink when also ack field
changes which will not be blocked by this change as it is not
duplicate ACK.
Signed-o
-off-by: Ilpo Järvinen <ilpo.jarvi...@helsinki.fi>
---
net/ipv4/tcp_input.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 0305f6d..1277afb 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3167,6 +3167,15 @@ stat
Here is a series of fixes to issues that occur when SACK is not
enabled for a TCP connection. These are not fixes to just some
remote corner cases of recovery but many/almost all recoveries
without SACK will be impacted by one (or even more than one) of
them. The bogus bursts that the sender side
No functional changes. This change simplifies the next change
slightly.
Signed-off-by: Ilpo Järvinen <ilpo.jarvi...@helsinki.fi>
---
net/ipv4/tcp_input.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
around to
the tcp_packet_delayed makes this change look more involved than
it really is.
The additional checks done in this change only affect non-SACK
case, the SACK case remains the same.
Signed-off-by: Ilpo Järvinen <ilpo.jarvi...@helsinki.fi>
---
net/ipv4/tcp_
On Wed, 7 Mar 2018, Yuchung Cheng wrote:
> On Wed, Mar 7, 2018 at 11:24 AM, Neal Cardwell <ncardw...@google.com> wrote:
> > On Wed, Mar 7, 2018 at 7:59 AM, Ilpo Järvinen <ilpo.jarvi...@helsinki.fi>
> > wrote:
> > >
> > > In a non-SACK cas
On Wed, 7 Mar 2018, Eric Dumazet wrote:
> > Currently non-SACK senders cannot identify almost any duplicate ACKs
> > because the window keeps updating for almost all ACKs. As a result,
> > non-SACK senders end up doing loss recovery only with RTO. RTO
> > recovery
> > without SACK is quite
Thanks for taking a look.
On Wed, 7 Mar 2018, Eric Dumazet wrote:
> On Wed, 2018-03-07 at 14:59 +0200, Ilpo Järvinen wrote:
> > Currently, the TCP code is overly eager to update window on
> > every ACK. It makes some of the ACKs that the receiver should
> > sent as dupACKs
No functional changes.
Signed-off-by: Ilpo Järvinen <ilpo.jarvi...@helsinki.fi>
---
net/ipv4/tcp_input.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 1a33752..e20f9ad 100644
--- a/net/ipv4/tcp_i
want to pass only the number of retransmitted segments
that were covered by the cumulative ACK (and potentially newly sent
data segments too if the cumulative ACK covers that far).
Signed-off-by: Ilpo Järvinen <ilpo.jarvi...@helsinki.fi>
---
net/ipv4/tcp_input.c | 19 +--
tp->snd_una.
Signed-off-by: Ilpo Järvinen <ilpo.jarvi...@helsinki.fi>
---
net/ipv4/tcp_input.c | 50 ++
1 file changed, 34 insertions(+), 16 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index e20f9ad..b689915 100644
--
Here is a series of fixes to issues that occur when SACK is not
enabled for a TCP connection:
tcp: feed correct number of pkts acked to cc modules
tcp: prevent bogus FRTO undos with non-SACK flows
tcp: move false FR condition into
tcp: prevent bogus undos when SACK is not enabled
tcp: send real
, no change to
window is applied if we are going to send a dupACK. It's ok
to change the window for non-dupACKs (such as the first ACK
after ofo arrivals start if that ACK was using delayed ACKs).
Signed-off-by: Ilpo Järvinen <ilpo.jarvi...@helsinki.fi>
---
include/linux/tcp.h | 3 ++-
ne
-SACK case.
Signed-off-by: Ilpo Järvinen <ilpo.jarvi...@helsinki.fi>
---
net/ipv4/tcp_input.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 0305f6d..1a33752 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2629,8 +2
B_CB(skb)->seq;
> + if (after(TCP_SKB_CB(skb)->end_seq, end))
> end = TCP_SKB_CB(skb)->end_seq;
> - } else {
> - if (before(TCP_SKB_CB(skb)->seq, start))
> - start = TCP_SKB_CB(skb)->seq;
> - if (after(TCP_SKB_CB(skb)->end_seq, end))
> - end = TCP_SKB_CB(skb)->end_seq;
> - }
> }
> }
I tried long to think if I could propose alternative layout which would
make this function to exit from the end but couldn't come up anything
sensible. As is, it's always exiting within that top if block which is
somewhat unintuitive :-).
Acked-By: Ilpo Järvinen <ilpo.jarvinen@helsinki>
--
i.
On Tue, 8 Dec 2015, Per Hurtig wrote:
> This patch implements the RTO restart modification (RTOR). When data is
> ACKed, and the RTO timer is restarted, the time elapsed since the last
> outstanding segment was transmitted is subtracted from the calculated RTO
> value. This way, the RTO timer
On Mon, 7 Dec 2015, Per Hurtig wrote:
> This patch implements the RTO restart modification (RTOR). When data is
> ACKed, and the RTO timer is restarted, the time elapsed since the last
> outstanding segment was transmitted is subtracted from the calculated RTO
> value. This way, the RTO timer
On Sat, 23 Feb 2008, Andrew Morton wrote:
On Wed, 20 Feb 2008 15:47:18 +0200 Ilpo Järvinen [EMAIL PROTECTED] wrote:
vmlinux.o:
62 functions changed, 66 bytes added, 10935 bytes removed, diff: -10869
...+ these to lib/jhash.o:
jhash_3words: 112
jhash2: 276
jhash: 475
On Sat, 23 Feb 2008, Andrew Morton wrote:
On Wed, 20 Feb 2008 15:47:10 +0200 Ilpo J__rvinen [EMAIL PROTECTED] wrote:
-41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR
This is a surprise.
It surprised me as well, there were something like 10 bytes I just
couldn't explain in IS_ERR
On Sat, 23 Feb 2008, Andi Kleen wrote:
Andrew Morton [EMAIL PROTECTED] writes:
-41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR
This is a surprise. I expect that the -mm-only
profile-likely-unlikely-macros.patch is the cause of this and mainline
doesn't have this problem.
Hi all,
I run some lengthy tests to measure cost of inlines in headers under
include/, simple coverage calculations yields to 89% but most of the
failed compiles are due to preprocessor cutting the tested block away
anyway. Test setup: v2.6.24-mm1, make allyesconfig, 32-bit x86,
gcc (GCC) 4.1.2
Hi all,
I run some lengthy tests to measure cost of inlines in headers under
include/, simple coverage calculations yields to 89% but most of the
failed compiles are due to preprocessor cutting the tested block away
anyway. Test setup: v2.6.24-mm1, make allyesconfig, 32-bit x86,
gcc (GCC) 4.1.2
()
should be rethought but I don't have a clue how to do that.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
include/linux/skbuff.h | 20 +---
net/core/skbuff.c | 21 +
2 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/include/linux/skbuff.h
-21593 356 funcs, 2418 +, 24011 -, diff: -21593 --- skb_push
Again, current_text_addr() needs to addressed.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
include/linux/skbuff.h | 18 +-
net/core/skbuff.c | 19 +++
2 files changed, 20 insertions
-23668 392 funcs, 104 +, 23772 -, diff: -23668 --- dev_alloc_skb
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
include/linux/skbuff.h | 17 +
net/core/skbuff.c | 18 ++
2 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/include/linux
-28162 354 funcs, 3005 +, 31167 -, diff: -28162 --- skb_pull
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
include/linux/skbuff.h | 15 +--
net/core/skbuff.c | 16
2 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/include/linux/skbuff.h
-10976 209 funcs, 123 +, 11099 -, diff: -10976 --- skb_trim
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
include/linux/skbuff.h | 16 +---
net/core/skbuff.c | 16
2 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/include/linux/skbuff.h
, diff: -6593
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
Cc: Vlad Yasevich [EMAIL PROTECTED]
---
include/net/sctp/sm.h |8 ++--
net/sctp/command.c| 12 +++-
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
index
vmlinux.o:
62 functions changed, 66 bytes added, 10935 bytes removed, diff: -10869
...+ these to lib/jhash.o:
jhash_3words: 112
jhash2: 276
jhash: 475
select for networking code might need a more fine-grained approach.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
drivers/infiniband
Codiff stats:
-16420 187 funcs, 103 +, 16523 -, diff: -16420 --- dst_release
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
include/net/dst.h | 10 +-
net/core/dst.c| 10 ++
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/include/net/dst.h b/include
On Wed, 20 Feb 2008, Jan Engelhardt wrote:
On Feb 20 2008 17:27, Patrick McHardy wrote:
Striking. How can this even happen? A callsite which calls
dev_alloc_skb(n)
is just equivalent to
__dev_alloc_skb(n, GFP_ATOMIC);
which means there's like 4 (or 8 if it's long) bytes
On Wed, 20 Feb 2008, Vlad Yasevich wrote:
Ilpo Järvinen wrote:
I added inline to sctp_add_cmd and appropriate comment there to
avoid adding another call into the call chain. This works at least
with gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-13). Alternatively,
__sctp_add_cmd could
Once again, one of this kind tries to creep in.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/ipv4/xfrm4_mode_beet.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/xfrm4_mode_beet.c b/net/ipv4/xfrm4_mode_beet.c
index e093a7b..b47030b 100644
--- a/net
to return to pre-split
state while more and more SACK info gets discovered.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
include/net/tcp.h|5 +
net/ipv4/tcp_input.c | 206 +-
2 files changed, 209 insertions(+), 2 deletions(-)
diff
On Fri, 1 Feb 2008, Ilpo Järvinen wrote:
@@ -1322,6 +1324,206 @@ static int tcp_sacktag_one(struct sk_buff *skb,
struct sock *sk,
return flag;
}
+/* Attempts to shift up to shiftlen worth of bytes from prev to skb.
+ * Returns number bytes shifted.
+ *
+ * TODO: in case
(tcp_mtup_init);
...yes, results from the recent move of tcp_is_cwnd_limited() away from
tcp.h.
Acked-by: Ilpo Järvinen [EMAIL PROTECTED]
--
i.
/bcast.h)
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
include/net/tipc/tipc_msg.h | 16
net/tipc/addr.h |5 -
net/tipc/bcast.h| 13 -
net/tipc/msg.h |5 -
4 files changed, 0 insertions(+), 39 deletions(-)
diff
it in
reality was).
This should solve the WARN_ONs in TCP code that as a result of
this triggered multiple times in every place we check for this
invariant.
Special thanks to Dave Young [EMAIL PROTECTED] and
Krishna Kumar2 [EMAIL PROTECTED] for trying with my debug
patches.
Signed-off-by: Ilpo
On Thu, 24 Jan 2008, Ilpo Järvinen wrote:
And anyway, there were some fackets_out related
problems reported as well and this doesn't help for that but I think I've
lost track of who was seeing it due to large number of reports :-), could
somebody refresh my memory because I currently don't
On Wed, 23 Jan 2008, Dave Young wrote:
On Jan 23, 2008 3:41 PM, Ilpo Järvinen [EMAIL PROTECTED] wrote:
On Tue, 22 Jan 2008, David Miller wrote:
From: Dave Young [EMAIL PROTECTED]
Date: Wed, 23 Jan 2008 09:44:30 +0800
On Jan 22, 2008 6:47 PM, Ilpo Järvinen [EMAIL PROTECTED
On Wed, 23 Jan 2008, Krishna Kumar2 wrote:
David Miller [EMAIL PROTECTED] wrote on 01/23/2008 01:27:23 PM:
iperf with multiple threads almost always gets these 4, *especially*
when I
do some batching :).
static void tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int
flag)
On Wed, 23 Jan 2008, Krishna Kumar2 wrote:
Hi Ilpo,
It's almost impossible to know which of these is the main cause and the
first occuring due to reasons I'll not copy here. What a strange thing
that it has been super quiet on this front until now everybody is seeing
it, could there be
On Wed, 23 Jan 2008, Ilpo Järvinen wrote:
On Wed, 23 Jan 2008, Dave Young wrote:
On Jan 23, 2008 3:41 PM, Ilpo Järvinen [EMAIL PROTECTED] wrote:
On Tue, 22 Jan 2008, David Miller wrote:
From: Dave Young [EMAIL PROTECTED]
Date: Wed, 23 Jan 2008 09:44:30 +0800
On Jan
On Wed, 23 Jan 2008, Ilpo Järvinen wrote:
On Wed, 23 Jan 2008, Krishna Kumar2 wrote:
Hi Ilpo,
It's almost impossible to know which of these is the main cause and the
first occuring due to reasons I'll not copy here. What a strange thing
that it has been super quiet on this front
On Wed, 23 Jan 2008, Krishna Kumar2 wrote:
While running with this patch, I got these errors (pasted at the end
of this mail).
I don't have a clue why it didn't go to the checking func (or it didn't
print anything) but just had those WARN_ONs... Hopefully this is giving
somewhat better input
On Tue, 22 Jan 2008, Dave Young wrote:
On Jan 22, 2008 12:37 PM, Dave Young [EMAIL PROTECTED] wrote:
On Jan 22, 2008 5:14 AM, Ilpo Järvinen [EMAIL PROTECTED] wrote:
On Mon, 21 Jan 2008, Dave Young wrote:
Please see the kernel messages following,(trigged while using some qemu
On Tue, 22 Jan 2008, Denys Fedoryshchenko wrote:
Just got on one of proxies, under high load.
It is a bit old rc, so probably my report not interesting, but since it is
production machines, i cannot change too often.
Kernel is 2.6.24-rc6-git11
It's not at all useless, there hasn't been any
On Tue, 22 Jan 2008, David Miller wrote:
From: Dave Young [EMAIL PROTECTED]
Date: Wed, 23 Jan 2008 09:44:30 +0800
On Jan 22, 2008 6:47 PM, Ilpo Järvinen [EMAIL PROTECTED] wrote:
[PATCH] [TCP]: debug S+L
Thanks, If there's new findings I will let you know.
Thanks for helping
On Mon, 21 Jan 2008, Patrick McHardy wrote:
Stephen Hemminger wrote:
Replace loop in dsmark_valid_indices with equivalent bit math.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- a/net/sched/sch_dsmark.c2008-01-20 13:07:58.0 -0800
+++
On Mon, 21 Jan 2008, Dave Young wrote:
Please see the kernel messages following,(trigged while using some qemu
session)
BTW, seems there's some e100 error message as well.
PCI: Setting latency timer of device :00:1b.0 to 64
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100:
I got a fixed commit back after
an RTT :-).
I wonder if getting it into your global GIT config file in proper
UTF8 encoding would fix things.
Put something like this into ~/.gitconfig
[user]
name = Ilpo Järvinen
email = [EMAIL PROTECTED
On Fri, 11 Jan 2008, Zhang, Yanmin wrote:
On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
The regression is:
1)stoakley with 2 qual-core processors: 11%;
2)Tulsa with 4 dual-core(+hyperThread) processors:13%;
I have new update on this issue and also cc to netdev maillist.
Thank
On Mon, 14 Jan 2008, Ilpo Järvinen wrote:
On Fri, 11 Jan 2008, Zhang, Yanmin wrote:
On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
As a matter of fact, 2.6.23 has about 6% regression and 2.6.24-rc's
regression is between 16%~11%.
I tried to use bisect to locate
On Sat, 12 Jan 2008, Stephen Hemminger wrote:
On Sat, 12 Jan 2008 11:40:10 +0200
Ilpo Järvinen [EMAIL PROTECTED] wrote:
...snip...
built-in.o:
12 functions changed, 250 bytes added, 1695 bytes removed, diff: -1445
...snip...
include/net/tcp.h | 35
On Sat, 12 Jan 2008, David Miller wrote:
From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Sat, 12 Jan 2008 14:59:50 +0200 (EET)
...Maybe I just fall-back to changing my last name, it's the only
full-proof solution... ;-)
Don't do this! Otherwise I won't have a frequent test case to make
Hi Dave,
First of all, I changed output encoding of git to utf-8, so I
guess the encoding should not cause the same trouble for you.
Here are couple of more to uninline things. Pretty
straightforward except the EXPORT_SYMBOLs, I've no idea which
is the right variant (feel free to fix them while
Hi Dave,
First of all, I changed output encoding to utf-8, so I guess
the encoding should not cause trouble for you.
Here are couple of more to uninline things. Pretty
straightforward except the EXPORT_SYMBOLs, I've no idea which
is the right variant (feel free to fix them while applying :-)).
functions changed, 7 bytes added, 7 bytes removed, diff: +0
net/ipv4/tcp_cong.c:
tcp_is_cwnd_limited | +88
1 function changed, 88 bytes added, diff: +88
built-in.o:
14 functions changed, 95 bytes added, 642 bytes removed, diff: -547
...Again some gcc artifacts visible as well.
Signed-off-by: Ilpo
functions changed, 36 bytes added, 894 bytes removed, diff: -858
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/core/pktgen.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index ebfb126..d18fdb1 100644
--- a/net/core
to be
generated). Still, the benefits are pretty obvious from the
codiff's results.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
Cc: Andi Kleen [EMAIL PROTECTED]
---
include/net/tcp.h | 35 +--
net/ipv4/tcp.c| 35 +++
2 files
:
5 functions changed, 300 bytes added, 782 bytes removed, diff: -482
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/ipv6/route.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 02354a7..d3b5811 100644
--- a/net/ipv6
, 535 bytes removed, diff: -482
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/netlink/af_netlink.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index be07f1b..21f9e30 100644
--- a/net/netlink/af_netlink.c
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/core/pktgen.c | 94 -
1 files changed, 0 insertions(+), 94 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index ede1fea..ebfb126 100644
--- a/net/core/pktgen.c
+++ b/net
Alternatively, this could be done by combining identical
parts of the match_policy_in/out()
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/netfilter/xt_policy.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netfilter/xt_policy.c b/net/netfilter/xt_policy.c
changed, 704 bytes added, 1384 bytes removed, diff: -680
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/xfrm/xfrm_policy.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 534b29e..47219f9 100644
--- a/net/xfrm
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/sched/sch_htb.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
index 72beb66..6a2352c 100644
--- a/net/sched/sch_htb.c
+++ b/net/sched/sch_htb.c
@@ -214,10 +214,6
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/core/utils.c | 11 ---
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/net/core/utils.c b/net/core/utils.c
index 34459c4..8031eb5 100644
--- a/net/core/utils.c
+++ b/net/core/utils.c
@@ -91,17 +91,6 @@ EXPORT_SYMBOL
On Sat, 12 Jan 2008, Herbert Xu wrote:
On Sat, Jan 12, 2008 at 09:40:17AM +, Ilpo Järvinen wrote:
Your emails are now using UTF-8 encoding but it's still declaring
ISO-8859-1 as the charset.
Thanks for trying to help but my situation is such that I think it got
also you confused
Hi Stephen,
Do you still remember what this is for (got added along with other TCP
hint stuff)? What kind of problem you saw back then (or who saw
problems)?
@@ -1605,6 +1711,10 @@ static void tcp_undo_cwr(struct sock *sk, const int
undo)
}
tcp_moderate_cwnd(tp);
On Tue, 8 Jan 2008, Ilpo Järvinen wrote:
On Mon, 7 Jan 2008, David Miller wrote:
From: Andi Kleen [EMAIL PROTECTED]
Date: Tue, 8 Jan 2008 06:00:07 +0100
On Mon, Jan 07, 2008 at 07:37:00PM -0800, David Miller wrote:
The vast majority of them are one, two, and three liners
On Sat, 5 Jan 2008, Arnaldo Carvalho de Melo wrote:
Em Sat, Jan 05, 2008 at 03:39:04PM +0200, Ilpo Järvinen escreveu:
Hi Dave,
After Arnaldo got codiff's inline instrumentation bugs fixed
(thanks! :-)), I got my .c-inline-bloat-o-meter to power up
reliably after some tweaking and bug
On Tue, 8 Jan 2008, John Heffner wrote:
Andi Kleen wrote:
David Miller [EMAIL PROTECTED] writes:
The big problem is that recovery from even a single packet loss in a
window makes us run kfree_skb() for a all the packets in a full
window's worth of data when recovery completes.
On Mon, 7 Jan 2008, David Miller wrote:
From: Andi Kleen [EMAIL PROTECTED]
Date: Tue, 8 Jan 2008 06:00:07 +0100
On Mon, Jan 07, 2008 at 07:37:00PM -0800, David Miller wrote:
The vast majority of them are one, two, and three liners.
% awk ' { line++ } ; /^{/ { total++; start = line
On Tue, 8 Jan 2008, Andi Kleen wrote:
David Miller [EMAIL PROTECTED] writes:
Similarly I question just about any inline usage at all in *.c files
Don't forget the .h files. Especially a lot of stuff in tcp.h should
be probably in some .c file and not be inline.
I'm not forgetting
On Mon, 7 Jan 2008, David Miller wrote:
Did you happen to read a recent blog posting of mine?
http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2007/12/31#tcp_overhead
I've been thinking more and more and I think we might be able
to get away with enforcing that SACKs are always
On Sun, 6 Jan 2008, Herbert Xu wrote:
is definitely not a fast path. If a function ends up being called
just once the compiler will most likely inline it anyway, making the
use of the keyword inline redundant.
Unexpected enough, even this logic seems to fail in a way with my gcc, I'm
yet to
On Sat, 5 Jan 2008, David Miller wrote:
From: Herbert Xu [EMAIL PROTECTED]
Date: Sun, 06 Jan 2008 11:29:35 +1100
We should never use inline except when it's on the fast path and this
is definitely not a fast path. If a function ends up being called
just once the compiler will most
[PATCH] [NET]: Remove obsolete comment
It seems that ip_build_xmit is no longer used in here and
ip_append_data is used.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
Hi Dave,
While reading some nearby code, I noticed this. I'm not 100%
sure if the removal is valid or not nor have
Hi Dave,
After Arnaldo got codiff's inline instrumentation bugs fixed
(thanks! :-)), I got my .c-inline-bloat-o-meter to power up
reliably after some tweaking and bug fixing on my behalf...
It shows some very high readings every now and then in the
code under net/.
...Aand... we've a sovereign
-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/ipv4/ipvs/ip_vs_xmit.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/ipvs/ip_vs_xmit.c b/net/ipv4/ipvs/ip_vs_xmit.c
index 1e96bf8..8436bf8 100644
--- a/net/ipv4/ipvs/ip_vs_xmit.c
+++ b/net/ipv4/ipvs/ip_vs_xmit.c
@@ -59,7
1 - 100 of 511 matches
Mail list logo
