Re: [9fans] 9p server to multiply 9p messages?

[hiro <23hiro@gmail.com>]

I don't think the reason nobody is doing this is that it's difficult per se.

Fcp also achieves parallelism without any changes to 9p.

And posix fs also share some of our statefulness.

A file system can have offsets, readahead can help.

Other synthetic FS need different tricks, but we can exchange some
guarantees that are only needed in seekable files for an optimization
that shall only be done on pipes and streaming access.

There's some trivial heuristic solutions for this but they are not
generic naturally.

If one were to do this right, after a few increments one will see that
bandwidth limits are hit, which is a new problem that is much harder
to solve and impossible without even more heuristics classifications
possibly applied by a distributed 9p scheduler (dynamic multi hop
network congestion awareness anybody?)

On 6/1/22, ron minnich <rminnich@gmail.com> wrote:
> On Tue, May 31, 2022 at 11:29 AM hiro <23hiro@gmail.com> wrote:
>>
>> so virtiofs is not using 9p any more?
>>
>> and with 10 million parallel requests, why shouldn't 9p be able to
>> deliver 10GB/s ?!
> 
> Everyone always says this. I used to say it too.
> 
> 9p requires a certain degree of ordering -- as Andrey once pointed
> out, it's not productive to close a file, then write it. So there is a
> tricky ordering requirement you need to get right, due to Plan 9 being
> stateful.
> 
> The way we use 9p in Plan 9, as a general purpose protocol for
> everything, like devices, requires that each Tread or Twrite occur in
> order, but also requires that each T be retired before the next T is
> issued. devmnt does  this. If you don't do this, hardware can get
> confused (e.g. ordering of Twrite followed by Tread followed by Twrite
> needs to be maintained. E.g. you don't want to issue the Tread before
> you know the Twrite happened.  E.g. pre-posting 100 Treads to
> /dev/mouse is not a good idea if you suddenly want to do a Twrite in
> the middle of it).
> 
> This is why 9p starts to perform poorly in networks with high
> bandwidth*delay products -- if you watch the net traffic, you see each
> T op  on fid blocked by the previous Reply (by devmnt).
> 
> I never figured out a way to fix this without fixing devmnt -- by
> removing its general nature.
> 
> But, more to the point, whether or not 9p should be able to do all
> these parallel requests and get high performance, nobody has yet done
> it. The only numbers ever reported for making high bandhwidth*delay
> networks better were in Floren's thesis, when he added Tstream.
> 
> After 20+ years of this discussion, I start to wondering whether it's
> harder than it looks.
> 
> ron

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T769854fafd2b7d35-M2be93c6a04bb2586cba3b797
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription