Hi Patrick,
I appreciate your comments.
I will update and resend patches.
> > +typedef long long gapclock_t;
>
> It seems you only add to this, does it need to be signed?
> How about using a fixed size type (u64) and getting rid
> of the typedef?
>
OK. I will use u64 instead of gapclock_t, and
Hi Eric,
> > +static struct sk_buff *alloc_gap_packet(struct Qdisc* sch, int size)
> > +{
> > + struct sk_buff *skb;
> > + struct net_device *dev = sch->dev;
> > + unsigned char *pkt;
> > + int pause_time = 0;
> > + int pktsize = size + 2;
> > +
> > + skb = alloc_skb(pktsize, GFP_ATOMI
Hi Patrick,
> Looks good, but please run checkpatch over it. A few more comments
> below.
>
I am sorry I forgot to run checkpatch.
Thanks for your comments. They are very useful for me.
I will fix them and resent the patch.
Best regards,
Ryousei Takano
-
To unsubscribe from this list: send the l
I am sorry I send an unfinished mail.
> > Also, the idea of using a PAUSE frame to add gaps is interesting, but
> > you should note that in linux a qdisc may be attached to any network
> > device and this for example maybe a PPP device etc. What would you use
> > for gaps in that case?
>
You are
RETRANS
> clearing. The problem was noticed because of a performance
> report from TAKANO Ryousei <[EMAIL PROTECTED]>.
>
> Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
> ---
> net/ipv4/tcp_input.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deleti
gt; This addition of lost_retrans_low to tcp_sock might be
> > unnecessary, it's not clear how often lost_retrans worker is
> > executed when there wasn't work to do.
> >
> > Cc: TAKANO Ryousei <[EMAIL PROTECTED]>
> > Signed-off-by: Ilpo Jär
From: David Miller <[EMAIL PROTECTED]>
Subject: Re: Regression in net-2.6.24?
Date: Thu, 11 Oct 2007 18:14:49 -0700 (PDT)
>
> Here is what I'm checking into net-2.6 for now:
>
> commit 6f535763165331bb91277d7519b507fed22034e5
> Author: David S. Miller <[EMAIL PROTECTED]>
> Date: Thu Oct 11 18:
From: "Ilpo Järvinen" <[EMAIL PROTECTED]>
Subject: Re: [RFC PATCH] [TCP]: Fix lost_retrans loop vs fastpath problems
Date: Thu, 11 Oct 2007 13:12:49 +0300 (EEST)
> > But, I got
> > a kernel panic at net_rx_action() in our experimental setting.
> > I am using the net-2.6.24 kernel _without_ this p
known, I've separated solution to that
> from this patch.
>
> Noticed because of report against a related problem from TAKANO
> Ryousei <[EMAIL PROTECTED]>. He also provided a patch to
> that part of the problem. This patch includes solution to it
> (though this patch h
Fix inconsistency of terms:
1) D-SACK
2) F-RTO
Signed-off-by: Ryousei Takano <[EMAIL PROTECTED]>
---
Documentation/networking/ip-sysctl.txt |6 +++---
net/ipv4/tcp_input.c | 16
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/Documentatio
From: "Ilpo Järvinen" <[EMAIL PROTECTED]>
Subject: Re: [RFC][PATCH 1/2] TCP: fix lost retransmit detection
Date: Mon, 8 Oct 2007 14:11:55 +0300 (EEST)
> On Sun, 7 Oct 2007, TAKANO Ryousei wrote:
>
> > From: "Ilpo Järvinen" <[EMAIL PROTECTED]>
>
From: David Miller <[EMAIL PROTECTED]>
Subject: Re: [RFC][PATCH 1/2] TCP: fix lost retransmit detection
Date: Sat, 06 Oct 2007 23:17:14 -0700 (PDT)
> From: TAKANO Ryousei <[EMAIL PROTECTED]>
> Date: Sun, 07 Oct 2007 14:51:00 +0900 (JST)
>
> > BTW, what is differenc
Hi Ilpo,
Thanks for your reply.
Most of my response are in the reply to patch 1/2.
From: "Ilpo Järvinen" <[EMAIL PROTECTED]>
Subject: Re: [RFC][PATCH 2/2] TCP: skip processing cached SACK blocks
Date: Fri, 5 Oct 2007 13:37:21 +0300 (EEST)
> On Thu, 4 Oct 2007, TAKANO Ryousei
From: "Ilpo Järvinen" <[EMAIL PROTECTED]>
Subject: Re: [RFC][PATCH 1/2] TCP: fix lost retransmit detection
Date: Fri, 5 Oct 2007 13:02:07 +0300 (EEST)
> On Thu, 4 Oct 2007, TAKANO Ryousei wrote:
>
> > This patch allows to detect loss of retransmitted packets more
This patch allows to process only newly reported SACK blocks at the
sender side. An ACK packet contains up to three SACK blocks, and some
of them may be already reported and processed blocks. This patch
prevents processing of such already processed SACK blocks.
Signed-off-by: Ryousei Takano <[EM
This patch allows to detect loss of retransmitted packets more
accurately by using the highest end sequence number among SACK
blocks. Before the retransmission queue is scanned, the highest
end sequence number (high_end_seq) is retrieved, and this value
is compared with the ack_seq of each packet
Hi all,
We found a performance problem which occurs in heavy packet loss
conditions. It seems there is a problem in detecting loss of
retransmitted packets.
In the retransmission queue, status of sent packets are registered.
When a packet is retransmitted, it is so marked, and snd_nxt (sequence
17 matches
Mail list logo
