Re: [RFC][PATCH] Avoid multi-page allocs for large mtu datagram sends

[Zach Brown <zach.brown@oracle.com>]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

Herbert Xu wrote:
> On Wed, Apr 05, 2006 at 05:51:02PM +0000, Zach Brown wrote:
>> 2) I changed the final-frag test to be length + fraggap as the math later on
>>    seemed to match that.. is that OK?
> 
> Yes that's a real bug introduced by a previous rework.  Could you
> please split that off into a separate patch?

Sure, here it is by itself.  I lightly tested this but didn't actually
use anything that has a non-zero trailer len, I don't think.

Did you have an opinion of the rest of the original patch?

- z



[-- Attachment #2: ip-append-data-fraggap-math-0.patch --]
[-- Type: text/x-patch, Size: 837 bytes --]


[PATCH] ip_output: account for fraggap when checking to add trailer_len

During other work I noticed that ip_append_data() seemed to be forgetting to
include the frag gap in its calculation of a fragment that consumes the rest of
the payload.  Herbert confirmed that this was a bug that snuck in during a
previous rework.

Signed-off-by: Zach Brown <zach.brown@oracle.com>

Index: 2.6.17-rc1-mm2-fraggap/net/ipv4/ip_output.c
===================================================================
--- 2.6.17-rc1-mm2-fraggap.orig/net/ipv4/ip_output.c
+++ 2.6.17-rc1-mm2-fraggap/net/ipv4/ip_output.c
@@ -904,7 +904,7 @@ alloc_new_skb:
 			 * because we have no idea what fragment will be
 			 * the last.
 			 */
-			if (datalen == length)
+			if (datalen == length + fraggap)
 				alloclen += rt->u.dst.trailer_len;
 
 			if (transhdrlen) {