Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics

[jamal <hadi@cyberus.ca>]

On Tue, 2005-03-29 at 17:00, Rik van Riel wrote:

>   However, we often will need
> to get the packets off the network card before we can decide
> whether or not they're high priority.

True - although one could argue that with NAPI that decision would be a
few opcodes away if you install the ingress qdisc. 
So you may end up allocing only to free a few cycles later. Increased
memory traffic but the discard happens sufficiently early for a s/ware
only solution and CPU cycles not burnt as much.

OTOH, even elcheapo pacific rim nics are beginning to show up with some
classifiers in the hardware as well as multiple queues or rx 
DMA rings. So you could program ACKs or all TCP packets to show up on a
higher priority ring and only process that until theres nothing left
before processing the low priority ring (i.e dont care if low priority
data/app is starved).
Probably someone going out of their way to do high performance iSCSI
would consider such hardware. 
We dont exactly support multiple rx (or tx) DMA rings however various
people seem to be promising patches that work with their hardware
(netiron, intel?)

> Also, there can be multiple high priority sockets, and we
> need to ensure they all make progress.  Hence the mempool
> idea.

Sorry missed the early part of this thread: mempool is some
strict priority scheme for mem allocation?

For Sockets: If there was a "control" arbitrator preferably in user
space which would install - after a socket open - both network ingress
and/or egress rules for prioritization then wouldnt that suffice?
The mechanisms are already in place today.

cheers,
jamal