When the date was Friday 19 August 2005 20:33, Jesse Brandeburg wrote:
> PS we have a driver in test that won't do the large contig allocations any
> more.
In fact, I tested a version of these drivers about 3 months ago and not only
they didn't solve the problem, but the throughput decreased!
Is
On Fri, 19 Aug 2005, Andi Kleen wrote:
> >> the formula for the size that the current e1000 looks for is something
> >> like
> >>
> >> a = MTU roundup to next power of 2
> >> a += 2 (skb_reserve(NET_IP_ALIGN))
> >> a += 16 (skb_reserve 16 by __dev_alloc_skb)
> >>
> >> so, a = 2048 + 2 + 16, or 20
I am sorry that the guy who found this problem is running suse linux,
but with vanilla kernel. so this is a generic problem, not suse
specific.
I am sorry for my insaneness at that time. :P
Ming
On Fri, 2005-08-19 at 20:01 +0200, Andi Kleen wrote:
> > I could certainly be mistaken. The differe
> I could certainly be mistaken. The difference I saw was that suse kernels
> recycle the same skb pointers back to our driver, and the redhat kernels
> seem to march through a much larger range before the values repeat. This
> is all observation based, so I may be completely wrong on this iss
On Fri, 2005-08-19 at 10:33 -0700, Jesse Brandeburg wrote:
> On Fri, 19 Aug 2005, Ming Zhang wrote:
> > This is first reported on IET list and then i redo the test with vanilla
> > 2.6.12.4 kernel and everything went fine.
> >
> > so i suspect if there are special case caused by vendor kernel.
> >
On Fri, 19 Aug 2005, Andi Kleen wrote:
> Ahh, okay. I'm pretty sure that SuSE did some changes (not sure what) to
> memory management.
I don't think so.
I could certainly be mistaken. The difference I saw was that suse kernels
recycle the same skb pointers back to our driver, and the redhat
> Ahh, okay. I'm pretty sure that SuSE did some changes (not sure what) to
> memory management.
I don't think so.
>
> the formula for the size that the current e1000 looks for is something
> like
>
> a = MTU roundup to next power of 2
> a += 2 (skb_reserve(NET_IP_ALIGN))
> a += 16 (skb_reser
On Fri, 19 Aug 2005, Ming Zhang wrote:
This is first reported on IET list and then i redo the test with vanilla
2.6.12.4 kernel and everything went fine.
so i suspect if there are special case caused by vendor kernel.
is this 32KB ATOMIC ram allocation request only available in jumbo frame
case
