On Wed, 2005-03-30 at 11:15, Andrea Arcangeli wrote:

quoted

The problem with you algorithm is that you cannot control
how to NIC puts incoming packets into RX rings (and then 
actually if the packets you are interested in do actually arrive from
the net ,-)

All I care about is to assign a mempool ID to the skb (ID being unique
identifier for the tcp connection I don't care how the implementation
is). 

Mechanisms are in place today.

If while moving up the stack the skb data doesn't match to the
sock->mempool id, we'll just free the packet and put it back in the
mempool.

I think you may need to reserve some small amount of buffers per NIC 
(<= RX DMA ring size) that are used as temporary buffers before the
decision is made to reassign to the higher priority memory or drop. 
The decision, if s/ware only, would need to consult a classifier at the
ingress (hopefully you are using NAPI and kick this only on overload).
The upgrade implies restoring the temporary buffer to the NIC.
The NIC rx side only makes progress if temp buffers are available.
Since they are restored a short distance after they are allocated
(whether you drop or upgrade) progress will always happen

quoted

"We have an enterprise class OS with iSCSI which can only
support four swap devices"

You forgot "carrier-grade" or is that supposed to conflict with
"enteprise class"? Cant you be both? ;->

;) I agree the hardware solution isn't appealing.

Well, if a realtek NIC (read: elcheapo, commodity) has such features -
in the minimal (regarless of the iscsi problem)- we need to support
those features.

cheers,
jamal