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
|