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

[ron minnich <rminnich@gmail.com>]

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-M71f56ad40eb62ce87f0917e3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription