From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrea Arcangeli Subject: Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics Date: Mon, 28 Mar 2005 18:22:00 +0200 Message-ID: <20050328162200.GC19137@g5.random> References: <20050324215922.GT14202@opteron.random> <424346FE.20704@cs.wisc.edu> <20050324233921.GZ14202@opteron.random> <20050325034341.GV32638@waste.org> <20050327035149.GD4053@g5.random> <20050327054831.GA15453@waste.org> <1111905181.4753.15.camel@mylaptop> <20050326224621.61f6d917.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Rik van Riel , Dmitry Yusupov , mpm@selenic.com, michaelc@cs.wisc.edu, open-iscsi@googlegroups.com, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com Return-path: To: Andi Kleen Content-Disposition: inline In-Reply-To: Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com List-Id: netdev.vger.kernel.org On Mon, Mar 28, 2005 at 06:12:39PM +0200, Andi Kleen wrote: > So in short using mempools on receiving is not needed. I think you are assuming that there's still some atomic memory available sometime in the future to allocate the skb for the ack, this isn't necessairly true. I outlined an algo that thanks to proper mempool-like reservation and random picking of all mempool registered on a single nic, will avoid the deadlock for receive. The less mempools there are and the bigger they are, the faster it will recover.