Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\s+2\.6\]\:\s+Fix\s+suboptimal\s+fragment\s+sizing\s+for\s+last\s+fragment\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\s+2\.6\]\:\s+Fix\s+suboptimal\s+fragment\s+sizing\s+for\s+last\s+fragment\s*$/: 22 ]

Total 22 documents matching your query.

1. [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment (score: 1): Author: xxxxxx>; Date: Thu, 02 Sep 2004 20:36:13 +0200; Yoshifuji's recent fragment patch prevents unnecessary fragmentation when the data can be kept in a single packet, but only for the first packet. When fragmenting, all fragments are still truncated t; /archives/netdev/2004-09/msg00062.html (20,622 bytes)
2. Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment (score: 1): Author: xxxxxx>; Date: Fri, 03 Sep 2004 04:48:23 +0900 (JST); Let me clarify. Are you sending payload of 2945 bytes (= udp payload of 2937 bytes)? Good point. I'll check this patch today. (Let me sleep for now...) Anyway, please update the comment instead of re; /archives/netdev/2004-09/msg00063.html (10,652 bytes)
3. Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment (score: 1): Author: en <ak@xxxxxxx>; Date: Thu, 2 Sep 2004 14:44:36 -0700; Looks great Patrick, applied. I see only one remaining possible improvement. If the fraggap area is paged data, we probably should try use page frags in the new SKB if this split occurs in ip_append_; /archives/netdev/2004-09/msg00067.html (9,414 bytes)
4. Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment (score: 1): Author: vem@xxxxxxxxxx>; Date: Fri, 3 Sep 2004 08:03:44 +1000; Yes. That could also tie into another optimisation. But it's an ugly one :) The sk->csum values are added up at the end of the processing so when we move bytes to and fro the total csum value stays t; /archives/netdev/2004-09/msg00068.html (11,074 bytes)
5. Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment (score: 1): Author: flipje@xxxxxxx>; Date: Thu, 2 Sep 2004 15:08:30 -0700; I have no problems with this. Please elaborate. Applied :-); /archives/netdev/2004-09/msg00070.html (10,348 bytes)
6. Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment (score: 1): Author: @xxxxxxxxxxxxx>; Date: Fri, 03 Sep 2004 10:40:50 +0900 (JST); I think I had similar impression when I saw the Patrick's patch. Here's the optimization: if we know the remaining data exceeds the mtu, we do not need to fill up full of it. skb_prev: mtu +--+--+-+; /archives/netdev/2004-09/msg00072.html (15,785 bytes)
7. Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment (score: 1): Author: leming <afleming@xxxxxxxxxxxxx>; Date: Tue, 7 Sep 2004 13:35:08 -0700; Has anyone tested or reviewed this patch? I'm just walking through my backlog trying to figure out what I need to spend time on.; /archives/netdev/2004-09/msg00176.html (9,906 bytes)
8. Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment (score: 1): Author: . Miller" <davem@xxxxxxxxxxxxx>; Date: Wed, 8 Sep 2004 09:15:57 +1000; I think that should be len < size, right? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbe; /archives/netdev/2004-09/msg00191.html (10,581 bytes)
9. Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment (score: 1): Author: u <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Wed, 08 Sep 2004 08:26:20 +0900 (JST); oh, right, thanks. Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@xxxxxxxxxxxxxx> == net/ipv4/ip_output.c 1.67 vs edited == -- 1.67/net/ipv4/ip_output.c 2004-09-03 06:50:20 +09:00 +++ edited/net/ipv4/ip_; /archives/netdev/2004-09/msg00192.html (15,231 bytes)
10. Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment (score: 1): Author: erbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Wed, 8 Sep 2004 13:21:58 +1000; Looks good. Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://; /archives/netdev/2004-09/msg00196.html (10,249 bytes)
11. Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment (score: 1): Author: >; Date: Wed, 8 Sep 2004 13:38:15 -0700; To me too, applied.; /archives/netdev/2004-09/msg00216.html (10,045 bytes)
12. [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment (score: 1): Author: Patrick McHardy <kaber@xxxxxxxxx>; Date: Thu, 02 Sep 2004 20:36:13 +0200; Yoshifuji's recent fragment patch prevents unnecessary fragmentation when the data can be kept in a single packet, but only for the first packet. When fragmenting, all fragments are still truncated t; /archives/netdev/2004-09/msg01518.html (20,442 bytes)
13. Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment (score: 1): Author: YOSHIFUJI Hideaki / <yoshfuji@xxxxxxxxxxxxxx>; Date: Fri, 03 Sep 2004 04:48:23 +0900 (JST); Let me clarify. Are you sending payload of 2945 bytes (= udp payload of 2937 bytes)? Good point. I'll check this patch today. (Let me sleep for now...) Anyway, please update the comment instead of re; /archives/netdev/2004-09/msg01519.html (10,700 bytes)
14. Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxx>; Date: Thu, 2 Sep 2004 14:44:36 -0700; Looks great Patrick, applied. I see only one remaining possible improvement. If the fraggap area is paged data, we probably should try use page frags in the new SKB if this split occurs in ip_append_; /archives/netdev/2004-09/msg01523.html (9,462 bytes)
15. Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Fri, 3 Sep 2004 08:03:44 +1000; Yes. That could also tie into another optimisation. But it's an ugly one :) The sk->csum values are added up at the end of the processing so when we move bytes to and fro the total csum value stays t; /archives/netdev/2004-09/msg01524.html (11,217 bytes)
16. Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxx>; Date: Thu, 2 Sep 2004 15:08:30 -0700; I have no problems with this. Please elaborate. Applied :-); /archives/netdev/2004-09/msg01526.html (10,467 bytes)
17. Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment (score: 1): Author: YOSHIFUJI Hideaki / <yoshfuji@xxxxxxxxxxxxxx>; Date: Fri, 03 Sep 2004 10:40:50 +0900 (JST); I think I had similar impression when I saw the Patrick's patch. Here's the optimization: if we know the remaining data exceeds the mtu, we do not need to fill up full of it. skb_prev: mtu +--+--+-+; /archives/netdev/2004-09/msg01528.html (15,904 bytes)
18. Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxx>; Date: Tue, 7 Sep 2004 13:35:08 -0700; Has anyone tested or reviewed this patch? I'm just walking through my backlog trying to figure out what I need to spend time on.; /archives/netdev/2004-09/msg01632.html (10,078 bytes)
19. Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Wed, 8 Sep 2004 09:15:57 +1000; I think that should be len < size, right? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbe; /archives/netdev/2004-09/msg01647.html (10,798 bytes)
20. Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment (score: 1): Author: YOSHIFUJI Hideaki / <yoshfuji@xxxxxxxxxxxxxx>; Date: Wed, 08 Sep 2004 08:26:20 +0900 (JST); oh, right, thanks. Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@xxxxxxxxxxxxxx> == net/ipv4/ip_output.c 1.67 vs edited == -- 1.67/net/ipv4/ip_output.c 2004-09-03 06:50:20 +09:00 +++ edited/net/ipv4/ip_; /archives/netdev/2004-09/msg01648.html (15,359 bytes)

Current List: 1 - 20
Page: [1] [2]