On Wed, 2005-03-30 at 11:15, Andrea Arcangeli wrote:
> > 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
> > "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
|