On Mon, 2005-03-28 at 18:12 +0200, Andi Kleen wrote:

This does not work because mempools assume you can sleep,
and in most NIC drivers you cant while doing RX refill.
The NIC drivers can be rewritten to do this refilling in
a workqueue. But it is not clear it is useful anyways because
Linux failing to allocate a buffer is no different from
the network overflowing the hardware queue of the network
device, which Linux cannot do anything about. 

Actually, not in 2.6 ... we had the same issue in SCSI using mempools
for sglist allocation.  All of the mempool alocation paths now take gfp_
flags, so you can specify GFP_ATOMIC for interrupt context.

Basically a network consists of lots of interconnected
queues, and even if you try to make the Linux specific
side of the queue reliable there are lots of other queues
that can still lose packets.

With TCP that is no problem of course because in case of 
a packet loss the packet is just retransmitted. 

So in short using mempools on receiving is not needed.

The object isn't to make the queues *reliable* it's to ensure the system
can make forward progress.  So all we're trying to ensure is that the
sockets used to service storage have some probability of being able to
send and receive packets during low memory.

In your scenario, if we're out of memory and the system needs several
ACK's to the swap device for pages to be released to the system, I don't
see how we make forward progress since without a reserved resource to
allocate from how does the ack make it up the stack to the storage
driver layer?

James