On Tue, 2005-03-29 at 17:17, Matt Mackall wrote:

I'm sure Rik realizes this, but it's important to note here that
"making progress" may require M acknowledgements to N packets
representing a single IO. So we need separate send and acknowledge
pools for each SO_MEMALLOC socket so that we don't find ourselves
wedged with M-1 available mempool slots when we're waiting on ACKs. So
accounting ACK packets to the appropriate receiver once we've figured
out what socket an ACK is intended for is critical.

Is this idea discussed or posted somewhere? I just subscribed to the
list.
Sounds like what the NICs i described do on rx - some strict priority
scheme.
Seems to me the TX side needs to be done early perhaps at the socket
layer.
The RX side needs to be done at the NIC or ingress qdisc.

I think there may be need for multiple levels of granularity of
priorities for mem allocation pools 8 or more if you want to have 
different levels of importantance in apps.
The deal with strict prio is the most important apps can eat all the
memory if they needed it; so you may need some form of deficit based
scheduling or kick in the algorithm only when a certain threshold is 
crossed system wide.

Note that ACK here is the application layer command result that needs
to be propagated back to the driver (and possibly higher in the case
of things like CD writing over iSCSI) and not simply a bit in the TCP
header.

I got that (given TCP is stream based).

cheers,
jamal