Adding a few virtio people. Please see the virtio spec/flag question
below.
On Tue, 12 Nov 2024, Chia-Yu Chang (Nokia) wrote:
> >From: Ilpo Järvinen
> >Sent: Thursday, November 7, 2024 8:28 PM
> >To: Eric Dumazet
> >Cc: Chia-Yu Chang (Nokia) ;
> >netdev@vger
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
ndoed, 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
On Wed, 28 Mar 2018, Yuchung Cheng wrote:
> On Wed, Mar 28, 2018 at 7:14 AM, Yuchung Cheng wrote:
> >
> > On Wed, Mar 28, 2018 at 5:45 AM, Ilpo Järvinen
> > wrote:
> > > On Tue, 27 Mar 2018, Yuchung Cheng wrote:
> > >
> > >> On Tue, M
On Wed, 28 Mar 2018, Yuchung Cheng wrote:
> On Tue, Mar 13, 2018 at 3:25 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
On Wed, 28 Mar 2018, Yuchung Cheng wrote:
> On Tue, Mar 13, 2018 at 3:25 AM, Ilpo Järvinen
> 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
> > false fast retransmits (RFC6582). The
On Tue, 27 Mar 2018, Yuchung Cheng wrote:
> On Tue, Mar 27, 2018 at 7:23 AM, Ilpo Järvinen
> wrote:
> > On Mon, 26 Mar 2018, Yuchung Cheng wrote:
> >
> >> On Tue, Mar 13, 2018 at 3:25 AM, Ilpo Järvinen
> >> wrote:
> >> >
> >> > A
On Mon, 26 Mar 2018, Yuchung Cheng wrote:
> On Tue, Mar 13, 2018 at 3:25 AM, Ilpo Järvinen
> wrote:
> >
> > A miscalculation for the number of acknowledged packets occurs during
> > RTO recovery whenever SACK is not enabled and a cumulative ACK covers
> > any non-
On Tue, 13 Mar 2018, Eric Dumazet wrote:
> On Tue, Mar 13, 2018 at 3:25 AM, Ilpo Järvinen
> 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
> > remote corner cases of reco
No functional changes. This change simplifies the next change
slightly.
Signed-off-by: Ilpo Järvinen
---
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
index c60745c..72ecfbb 100644
--- a
(and potentially newly sent
data segments too if the cumulative ACK covers that far).
Signed-off-by: Ilpo Järvinen
---
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_input.c
index 9a1b3c1..4a26c09
w did 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.
Sig
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 m
und 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
---
net/ipv4/tcp_input.c | 42 ++
1 file c
igned-off-by: Ilpo Järvinen
---
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 @@ static int tcp_clean_rtx_queue(s
On Fri, 9 Mar 2018, David Miller wrote:
> From: Ilpo Järvinen
> 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 messages so
> >
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
> 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 messages so
> >
On Wed, 7 Mar 2018, Yuchung Cheng wrote:
> On Wed, Mar 7, 2018 at 12:19 PM, Neal Cardwell wrote:
> >
> > On Wed, Mar 7, 2018 at 7:59 AM, Ilpo Järvinen
> > wrote:
> > > A bogus undo may/will trigger when the loss recovery state is
> > > k
(and potentially newly sent
data segments too if the cumulative ACK covers that far).
Signed-off-by: Ilpo Järvinen
---
net/ipv4/tcp_input.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 9a1b3c1..0305f6d
w did 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.
Sig
igned-off-by: Ilpo Järvinen
---
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 @@ static int tcp_clean_rtx_queue(s
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 f
No functional changes. This change simplifies the next change
slightly.
Signed-off-by: Ilpo Järvinen
---
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
index 1277afb..4ccba94 100644
--- a
und 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
---
net/ipv4/tcp_input.c | 42 ++
1 file c
On Wed, 7 Mar 2018, Yuchung Cheng wrote:
> On Wed, Mar 7, 2018 at 11:24 AM, Neal Cardwell wrote:
> > On Wed, Mar 7, 2018 at 7:59 AM, Ilpo Järvinen
> > wrote:
> > >
> > > In a non-SACK case, any non-retransmitted segment acknowledged will
> > > set F
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 anno
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
---
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_input.c
+++ b/net/ipv4/tcp_input.c
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
---
net/ipv4/tcp_input.c | 19 +--
1 file changed, 17 insertions(+), 2
tp->snd_una.
Signed-off-by: Ilpo Järvinen
---
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
--- a/net/ipv4/tcp_input.c
+++ b/ne
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 du
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
---
include/linux/tcp.h | 3 ++-
net/ipv4/tcp_input.c | 5 -
-SACK case.
Signed-off-by: Ilpo Järvinen
---
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 +2629,13 @@ static void
(unlikely(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;
> - } 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
--
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 will
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 will
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 t
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 i
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/jh
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)". Al
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
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/infi
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/i
es removed, 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
-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
-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
-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
()
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/in
-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 inse
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 20
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 20
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
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.
arge cumulative ACK comes. Try 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
c_mss);
> -EXPORT_SYMBOL(sysctl_tcp_tso_win_divisor);
> EXPORT_SYMBOL(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.
t/tipc/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(+),
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 memo
its which won't be set with it at all.
Effectively, NewReno should always exists after the first
iteration anyway (or immediately if there's already head in
lost_out.
This was fixed earlier in net-2.6.25 but got reverted among other
stuff and I didn't notice that this is still ne
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 inpu
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: "Dav
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 st
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
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_a
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 20
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
> >
>
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 a
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:
> > >
>
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
>
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
> > +++ b/net/sch
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
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.
recently
added (wasn't available at early dawn of git era), before that it was just
a mess locally. Funny enough, you were able to magically mangle my emails
to utf-8'ed commits nicely back then so I got a "fixed" commit back after
an RTT :-).
> I wonder if getting it into
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 ca
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
On Sat, 12 Jan 2008, Herbert Xu wrote:
> On Sat, Jan 12, 2008 at 09:40:17AM +0000, 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
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
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
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
---
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
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_po
es 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
:
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/ne
, 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_net
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/ne
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 :-)).
Al
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 a
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);
tp->snd
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:
> > &g
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 compl
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
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 in
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 forgettin
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++;
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
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
| -192
ccid3_hc_tx_send_packet | -144
5 functions changed, 850 bytes removed, diff: -850
net/dccp/ccids/ccid3.c:
ccid3_update_send_interval | +191
1 function changed, 191 bytes added, diff: +191
net/dccp/ccids/ccid3.o:
6 functions changed, 191 bytes added, 850 bytes removed, diff: -659
Signed-off-by
functions changed, 2122 bytes added, 11029 bytes removed, diff: -8907
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/netfilter/nf_conntrack_netlink.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/netfilter/nf_conntrack_netlink.c
1 - 100 of 528 matches
Mail list logo
