Re: [PATCH] tcpdump may trace some outbound packets twice.
On Tue, May 16, 2006 at 02:21:27AM +0200, Patrick McHardy wrote: David S. Miller wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Mon, 15 May 2006 16:41:01 -0700 kfree_skb(NULL) is legal so the conditional here is unneeded. But the increased calls to kfree_skb(NULL) would probably bring the unlikely() hordes descending on kfree_skb, so maybe: And unfortunately as Patrick McHardy states, we can't use this trick here because things like tc actions can do stuff like pskb_expand_head() which cannot handle shared SKBs. We need another solution to this problem, because cloning an extra SKB is just rediculious overhead so isn't something we can seriously consider to solve this problem. Another option is to say this anomaly doesn't matter enough to justify the complexity we're looking at here just to fix this glitch. Other implementation possibility suggestions welcome :-) We could just mark the skb to make sure its only passed to taps on the first transmission attempt. Since we have the timestamp optimization there shouldn't be any visible change besides the desired effect. It would be nice to have a solution that taps after its been sent to the driver. I clearly need to investigate the tc problems, but I've been using a similar patch now for a few weeks to allow more accurate timestamps to be performed in the driver without cloning problems getting in the way. (the tap skb only gets cloned after the driver has time stamped it). This is more accuracy than most need but is required for the clock synchronisation i'm working on. It also seems less intrusive to let the driver have the skb first before pushing it to the taps. Tom -- Thomas Young http://cubinlab.ee.unimelb.edu.au/~tyo/ Research Assistant CUBIN Research Centre - University of Melbourne - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Vegas bug in kernel v2.6.15
On Tue, 2006-01-10 at 16:09 +0100, Tarjan Peter wrote: Hello, We have done some measurements on kernel v2.6.14.2 and v2.6.15 with TCP Vegas. It seems that Vegas implementation in v2.6.15 is broken: it stops increasing congestion window after reaching a certain limit. For example in a 500 Mbps channel its goodput is between 20 Mbps and 200 Mbps. But in v2.6.14.2 it is okay. If you need more information, throughput graphs etc., contact us. Best regards, Peter Hello, Is this a problem that the recent slow start patch hasn't fixed? Your description makes it sound more like a congestion avoidance, problem. I've spent some of today playing with vegas on my test network (10mb bottleneck), and haven't seen any obvious problems. I'd be interested in seeing any traces that show performance problems with the vegas implementation. Thanks, -- Thomas Young http://cubinlab.ee.unimelb.edu.au/~tyo/ Research Assistant CUBIN Research Centre - University of Melbourne - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] TCP_Vegas: Fix slow start
Vegas' slow start was only adding one MSS per RTT rather than one for every ack. Slow start behavior should now match Reno. Signed-off-by: Thomas Young [EMAIL PROTECTED] --- net/ipv4/tcp_vegas.c |4 1 files changed, 4 insertions(+), 0 deletions(-) aa4db8a59aede2955461910e1516826fd85135a2 diff --git a/net/ipv4/tcp_vegas.c b/net/ipv4/tcp_vegas.c --- a/net/ipv4/tcp_vegas.c +++ b/net/ipv4/tcp_vegas.c @@ -330,6 +330,10 @@ static void tcp_vegas_cong_avoid(struct vegas-cntRTT = 0; vegas-minRTT = 0x7fff; } + /* Use normal slow start */ + else if (tp-snd_cwnd = tp-snd_ssthresh) + tcp_slow_start(tp); + } /* Extract info for Tcp socket info provided via netlink. */ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] TCP_Vegas: Remove extra call to tcp_vegas_rtt_calc
On Tue, 2005-12-06 at 17:04 -0800, David S. Miller wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Tue, 6 Dec 2005 10:52:09 -0800 Fixing Vegas was on my TODO list, thanks for attacking it. It never really worked well. Indeed, thanks a lot Tom. I've integrated the three fixes. Excellent. Thank you both for the review and improvements to my proposed fixes. Tom - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] TCP_Vegas: fix RTT measurement
Vegas RTT measurement currently seems quite broken. I've identified three issues. 1) The reseting the rtt stats is for every call to cong_avoid rather than at the end of the rtt. 2) Also, timestamping is being performed after the skb clone, leading to non-sensical RTT estimates. The patch below fixes this by timestamping the original skbs before calling tcp_transmit_skb. Timestamping is now done everywhere where skb-when is set in tcp_output.c. 3) The measuring of the RTT inside tcp_cong_avoid is redundent as far as I can tell. This call is made (with the micro second resolution) just prior to the call to tcp_vegas_cong_avoid Thomas Young - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] TCP_Vegas: Remove extra call to tcp_vegas_rtt_calc
On Mon, 2005-12-05 at 21:43 -0800, David S. Miller wrote: From: Tom Young [EMAIL PROTECTED] Date: Tue, 06 Dec 2005 15:40:57 +1100 Remove unneeded call to tcp_vegas_rtt_calc. The more accurate microsecond value has already been registered prior to calling tcp_vegas_cong_avoid. Signed-off-by: Thomas Young [EMAIL PROTECTED] This patch pretty much looks ok, will just wait for an ACK from Stephen. In general, the vegas implementation seems to have been in a quite broken state. Are you doing real testing of this cwnd module or is this all from code inspection? Thanks a lot. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Mostly testing, I'm experementing with a vegas fork that uses queing delay feedback from routers to replace baseRTT. I noticed with 2.6.14 that the rtt's were all 0. Updating to the latest linus tree yesterday got the current situation where the rtts were 'now'. Thanks, Tom - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.14] ipv4: ip_queue_xmit ip id increment off by one
On Mon, 2005-11-07 at 16:16 -0800, David S. Miller wrote: TCP ends up setting it to 1 but other protocols do not. But other protocols use ip_queue_xmit() as well, such as DCCP and SCTP, and they won't change it from it's alloc_skb() time value of 0. Thanks for clearing that up, I see that I was being too TCP-centric now in my see if I broke anything testing. My patch solves my immediate needs, but I will revisit this later and attempt a more generic solution if time permits. Thanks, Tom - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.14] ipv4: ip_queue_xmit ip id increment off by one
I'm resubmitting this as I think while its effect is minimal in most cases, it does still fix a bug. The current implemenation effectly halfs the ip id space because of the off by one error. This could lead to problems on LFNs. The socket ip id currently gets incremented by 1 + the number of segments leading to an increment of 2 in the standard non-TSO case. This patch fixes 'more' to be a count of extra segments. Signed-off-by: Thomas Young [EMAIL PROTECTED] --- diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c @@ -352,7 +352,7 @@ packet_routed: ip_options_build(skb, opt, inet-daddr, rt, 0); } - ip_select_ident_more(iph, rt-u.dst, sk, skb_shinfo(skb)-tso_segs); + ip_select_ident_more(iph, rt-u.dst, sk, skb_shinfo(skb)-tso_segs - 1); /* Add an IP checksum. */ ip_send_check(iph); - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
