On Tue, May 31, 2022 at 11:29 AM hiro <23h...@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
