From: "Alex Aizman" <itn780@yahoo.com>
To: <open-iscsi@googlegroups.com>, "'Rick Jones'" <rick.jones2@hp.com>
Cc: "'netdev'" <netdev@oss.sgi.com>, <ksummit-2005-discuss@thunk.org>
Subject: RE: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics
Date: Tue, 29 Mar 2005 18:28:25 -0800 [thread overview]
Message-ID: <200503300228.j2U2Slul009687@oss.sgi.com> (raw)
In-Reply-To: <1112138018.1088.31.camel@jzny.localdomain>
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
next prev parent reply other threads:[~2005-03-30 2:28 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4241D106.8050302@cs.wisc.edu>
[not found] ` <20050324101622S.fujita.tomonori@lab.ntt.co.jp>
[not found] ` <1111628393.1548.307.camel@beastie>
[not found] ` <20050324113312W.fujita.tomonori@lab.ntt.co.jp>
[not found] ` <1111633846.1548.318.camel@beastie>
[not found] ` <20050324215922.GT14202@opteron.random>
[not found] ` <424346FE.20704@cs.wisc.edu>
[not found] ` <20050324233921.GZ14202@opteron.random>
[not found] ` <20050325034341.GV32638@waste.org>
[not found] ` <20050327035149.GD4053@g5.random>
2005-03-27 5:48 ` [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics Matt Mackall
2005-03-27 6:04 ` Andrea Arcangeli
2005-03-27 6:38 ` Matt Mackall
2005-03-27 14:50 ` Andrea Arcangeli
2005-03-27 6:33 ` Dmitry Yusupov
2005-03-27 6:46 ` David S. Miller
2005-03-27 7:05 ` Dmitry Yusupov
2005-03-27 7:57 ` David S. Miller
2005-03-27 8:18 ` Dmitry Yusupov
2005-03-27 18:26 ` Mike Christie
2005-03-27 18:31 ` David S. Miller
2005-03-27 19:58 ` Matt Mackall
2005-03-27 21:49 ` Dmitry Yusupov
2005-03-27 18:47 ` Dmitry Yusupov
2005-03-27 21:14 ` Alex Aizman
[not found] ` <20050327211506.85EDA16022F6@mx1.suse.de>
2005-03-28 0:15 ` Andrea Arcangeli
2005-03-28 3:54 ` Rik van Riel
2005-03-28 4:34 ` David S. Miller
2005-03-28 4:50 ` Rik van Riel
2005-03-28 6:58 ` Alex Aizman
2005-03-28 16:12 ` Andi Kleen
2005-03-28 16:22 ` Andrea Arcangeli
2005-03-28 16:24 ` Rik van Riel
2005-03-29 15:11 ` Andi Kleen
2005-03-29 15:29 ` Rik van Riel
2005-03-29 17:03 ` Matt Mackall
2005-03-28 16:28 ` James Bottomley
2005-03-29 15:20 ` Andi Kleen
2005-03-29 15:56 ` James Bottomley
2005-03-29 17:19 ` Dmitry Yusupov
2005-03-29 21:08 ` jamal
2005-03-29 22:00 ` Rik van Riel
2005-03-29 22:17 ` Matt Mackall
2005-03-29 23:30 ` jamal
2005-03-29 23:00 ` jamal
2005-03-29 23:25 ` Matt Mackall
2005-03-30 0:30 ` H. Peter Anvin
2005-03-30 15:24 ` Andi Kleen
2005-03-29 22:03 ` Rick Jones
2005-03-29 23:13 ` jamal
2005-03-30 2:28 ` Alex Aizman [this message]
[not found] ` <E1DGSwp-0004ZE-00@thunker.thunk.org>
2005-03-30 17:16 ` Grant Grundler
2005-03-30 18:46 ` Dmitry Yusupov
2005-03-30 15:22 ` Andi Kleen
2005-03-30 15:33 ` Andrea Arcangeli
2005-03-30 15:38 ` Rik van Riel
2005-03-30 15:39 ` Andi Kleen
2005-03-30 15:44 ` Andrea Arcangeli
2005-03-30 15:50 ` Rik van Riel
2005-03-30 16:04 ` James Bottomley
2005-03-30 17:48 ` H. Peter Anvin
2005-03-30 16:02 ` Andi Kleen
2005-03-30 16:15 ` Andrea Arcangeli
2005-03-30 16:55 ` jamal
2005-03-30 18:42 ` Rik van Riel
2005-03-30 19:28 ` Alex Aizman
2005-03-31 11:41 ` Andi Kleen
2005-03-31 12:12 ` Rik van Riel
2005-03-31 18:59 ` Andi Kleen
2005-03-31 19:04 ` Rik van Riel
2005-03-31 15:35 ` Grant Grundler
2005-03-31 19:15 ` Alex Aizman
2005-03-31 19:34 ` Andi Kleen
2005-03-31 19:39 ` Rik van Riel
2005-03-31 11:45 ` Andi Kleen
2005-03-31 11:50 ` Andi Kleen
2005-03-31 17:09 ` Andrea Arcangeli
2005-03-31 22:05 ` Dmitry Yusupov
2005-03-30 17:24 ` Matt Mackall
2005-03-30 17:39 ` Dmitry Yusupov
2005-03-30 20:10 ` Mike Christie
2005-03-30 17:07 ` Grant Grundler
2005-03-30 5:12 ` H. Peter Anvin
2005-03-28 16:37 ` Dmitry Yusupov
2005-03-28 19:45 ` Roland Dreier
2005-03-28 20:32 ` Topic: Remote DMA network technologies Gerrit Huizenga
2005-03-28 20:36 ` Roland Dreier
[not found] ` <1112042936.5088.22.camel@beastie>
2005-03-28 22:32 ` [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics Benjamin LaHaise
2005-03-29 3:19 ` Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) Roland Dreier
2005-03-30 16:00 ` Benjamin LaHaise
2005-03-31 1:08 ` Linux support for RDMA H. Peter Anvin
2005-04-02 18:08 ` [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics Dmitry Yusupov
2005-04-02 19:13 ` Ming Zhang
2005-04-04 6:31 ` Grant Grundler
2005-04-04 18:57 ` Rick Jones
2005-03-29 3:14 ` Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) Roland Dreier
[not found] <42472259.2866086e.3169.318fSMTPIN_ADDED@mx.googlegroups.com>
2005-03-27 21:18 ` [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics Alex Aizman
2005-03-27 21:53 Alex Aizman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200503300228.j2U2Slul009687@oss.sgi.com \
--to=itn780@yahoo.com \
--cc=ksummit-2005-discuss@thunk.org \
--cc=netdev@oss.sgi.com \
--cc=open-iscsi@googlegroups.com \
--cc=rick.jones2@hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.