From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Fri, 30 Apr 2010 12:13:59 -0400 To: 9fans@9fans.net Message-ID: In-Reply-To: <20100430155903.A6BF25B2E@mail.bitblocks.com> References: <5fa9fbfe115a9cd5a81d0feefe413192@quintile.net> <4fa1305e0f56a0ef89c2e05320fa5997@coraid.com> <40cf59cfc2735e232f0fd67df725e65d@kw.quanstro.net> <046b9c874815d108c6ffb7a857e847a7@kw.quanstro.net> <20100429170859.2EBE05B78@mail.bitblocks.com> <20100430155903.A6BF25B2E@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: Re: [9fans] A simple experiment Topicbox-Message-UUID: 14fa2808-ead6-11e9-9d60-3106f5b1d025 > > i don't see any reason why 9p couldn't use some of the same > > congestion control ideas. the trick would be to feed back packet loss > > detection and retransmission info to the point where file io gets > > turned into rpcs→the mount driver > > Agreed -- sort of what I meant by "I hope 9p evolves". > Though I'd probably stick this in a layer below 9p. i suggested putting it above 9p. i don't understand your suggestion. how would a layer below know that there is more data? > It can > backpressure a 9p client if it tries to send too much (either > by blocking or returning with equiv of EWOULDBLOCK). isn't that what you just complained about—fcp having to do the kernel's work? i think EWOULDBLOCK would be a big mistake. io in plan 9 is synchronous. and this is very much on purpose. - erik