Re: [RFC][PATCH] avoid multi page allocs in ip_append_data

2006-03-31 Thread Zach Brown
> For the else clause wouldn't we be counting fragheaderlen twice if > the multi page if falls through above despite NETIF_F_SG being true? Looks like, yeah. I'll fix up and resend. Thanks for the sharp eyes. - z - To unsubscribe from this list: send the line "unsubscribe netdev" in the body o

Re: [RFC][PATCH] avoid multi page allocs in ip_append_data

2006-03-31 Thread Herbert Xu
Zach Brown <[EMAIL PROTECTED]> wrote: > > Index: 2.6.16-mm2-bigmtu/net/ipv4/ip_output.c > === > --- 2.6.16-mm2-bigmtu.orig/net/ipv4/ip_output.c > +++ 2.6.16-mm2-bigmtu/net/ipv4/ip_output.c > @@ -891,13 +891,26 @@ alloc_new_skb: >

Re: [RFC][PATCH] avoid multi page allocs in ip_append_data

2006-03-31 Thread Zach Brown
> What exactly are you trying to do with that "watch out for trailer_len" > thing where you subtract 2 from datalen? The danger is in chosing a datalen that just fits in a page but then finding that it == length and so we want to add on trailer_len, bringing the alloc back over a page. The logic

Re: [RFC][PATCH] avoid multi page allocs in ip_append_data

2006-03-31 Thread David S. Miller
From: Zach Brown <[EMAIL PROTECTED]> Date: Thu, 30 Mar 2006 15:00:30 -0800 > We've had reports from customers of boxes with a week's uptime and 32k MTUs > getting failed order-3 allocs under: > > udp_sendmsg .. ip_append_data .. {sock_wmalloc, sock_alloc_send_skb} > > I came up with the fo

Re: [RFC][PATCH] avoid multi page allocs in ip_append_data

2006-03-30 Thread Zach Brown
> + /* watch out for trailer_len */ > + if (datalen == length) > + datalen -= 2; Hmm, that probably needs to be more careful :/ - z - To unsubscribe from this list: send the line "unsubscribe netdev" in t

[RFC][PATCH] avoid multi page allocs in ip_append_data

2006-03-30 Thread Zach Brown
We've had reports from customers of boxes with a week's uptime and 32k MTUs getting failed order-3 allocs under: udp_sendmsg .. ip_append_data .. {sock_wmalloc, sock_alloc_send_skb} I came up with the following which seems to do the right thing in a trivial test. It clamps the size of t