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->features&NETIF_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 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

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 int

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? Than

[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 up