Jamal wrote:
>
> >
> > Eventually the TCP will hit its RTX limit and punt the connection,
> > freeing the buffers kept for retransmission right?
> >
>
> If i read correctly the people arguing for iscsi say thats
> not good enough. But they may be having other issues too...
It is not good enough for storage.
If we continue to fall back into TCP-will-eventually-recover mentality
iSCSI, or at least a "soft" non-offloaded iSCSI over regular non-TOE TCP,
will not be able to compete with FC, which uses determinstic credit-based
flow control. That non-determinism is a bigger issue, while a corner case
like swap device happenning to be iSCSI-remote is just that, a corner case
that helps to highlight and bring the general problem to the foreground.
Adding a "critical" or "resource-protected" attribute to the connection
context is a step in the right direction. Next steps include:
- triage (closing non-critical connections in OOM);
- socket reopen without deallocating memory (something like: close(int
socket_fd, int will_reopen));
- preallocated mempools (it is much better to discover OOM at connection
open time than well into runtime).
- better resource "counting" throughout the L3 and L4 layers to preventively
handle OOM;
And more incremental steps like that.
Alex
|