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

2006-04-13 Thread Herbert Xu
Hi Zach: On Wed, Apr 05, 2006 at 05:51:02PM +, Zach Brown wrote: + if ((rt-u.dst.dev-featuresNETIF_F_SG) + (SKB_DATA_KMALLOC_BYTES(alloclen + datalen) + PAGE_SIZE)) { +

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

2006-04-12 Thread Herbert Xu
On Wed, Apr 05, 2006 at 05:51:02PM +, 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?

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

2006-04-12 Thread Zach Brown
Herbert Xu wrote: On Wed, Apr 05, 2006 at 05:51:02PM +, 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

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

2006-04-12 Thread Herbert Xu
On Wed, Apr 12, 2006 at 11:22:58AM -0700, Zach Brown wrote: Did you have an opinion of the rest of the original patch? Sorry, I've been busy lately so I've only just started reading it. I should have something to say by tomorrow :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert

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

2006-04-05 Thread Zach Brown
OK, here's a stronger attempt. I might have gone a little wild with the patch description :). Two questions and a data point: 1) It occurs to me as I write this that I don't know how the trailer_len stuff works if a fragments final data bits are page frags in the skb. Did I screw this