9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "David Arroyo" <droyo@aqwari.net>
To: "Kyle Farwell via 9fans" <9fans@9fans.net>
Subject: Re: [9fans] Dual dialing/forking sessions to increase 9P throughput
Date: Wed, 27 Jan 2021 19:17:48 -0500	[thread overview]
Message-ID: <829ad45b-941b-46f9-acef-7eddf541104f@www.fastmail.com> (raw)
In-Reply-To: <21AE5944012F26AD61546F797F677050@eigenstate.org>

On Wed, Jan 27, 2021, at 11:25, Ethan Gardener wrote:
> fcp(1)? 

You are right, but fcp(1) would only produce multiple parallel read
and write messages, I'm talking about a more general approach. fcp is
probably a better compromise, though, as ori points out the client can
get complicated pretty quickly when trying to solve the problem more
generally:

On Wed, Jan 27, 2021, at 11:52, ori@eigenstate.org wrote:
> This also has some hairy edge cases. For example,
> what happens to the actions in the pipeline if one
> of the operations fails?

Yes, the tradeoff of this pipelining is that the client becomes a lot
more complex, but for this specific problem, the client would need to be
prepared to receive and discard Rerror messages for each message after
the failed one, just surfacing the first error to whatever system call
or library function kicked off this sequence of messages.

> I think that for this kind of pipelining to be
> effective, 9p may need some notion of 'bundles',
> where the first failure, short write, or other
> exceptional operation would cause all other
> commands in the bundle to be ignored.

You can get pretty close to "bundles" without changing the protocol by
having the client reserve a few bits of storage in the Tag header to
group requests in a pipeline together:

# Bundle 1, sent at once
Twalk tag=0x0100 fid=0 newfid=1 "foo/bar"
Topen tag=0x0101 fid=1 O_RDONLY
Twrite tag=0x0102 fid=1 data
Tclunk tag=0x0103 fid=1

Then the client could use a trie or some similar data structure on the
tag of an R-message to get the "state" of a pipeline.

> Another issue is that its' difficult to retrofit
> this pipelining into the plan 9 system call
> interface; when do you return an error from
> read(2)? what if there are mutiple Treads?

This is a harder problem, I think. What if non-contiguous reads or writes
succeed? An mmap()-style API might fare better here, but that comes with
its own drawbacks. I don't have a good answer here, but I think since
Twrite and Rread messages are elastic it is always better to just send
larger messages, increasing msize if necessary.

> how do you handle congestion if you can stuff as many 9p packets down
> a single connection as possible? There's no packet loss, but you can
> end up with very long delays as small reads like /dev/mouse get queued
> behind bulk transfers.

The problem you describe is analagous to the "buffer bloat" problem.
In the lower protocols like TCP it is solved by making the sender aware of
the bandwidth delay product and sizing its buffers appropriately. So it
could be handled by using a model-based congestion avoidance algorithm
like BBR or Vegas, and sending messages out of a prioritized queue,
where "interactive" files like /dev/mouse are prioritized.

David

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te69bb0fce0f0ffaf-M6e7a64ad95ea27ac3c73a9ac
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

      parent reply	other threads:[~2021-01-28  0:18 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-29 23:50 cigar562hfsp952fans
2020-12-30  8:12 ` [9fans] " joey
2021-01-03 23:51 ` [9fans] " Ethan Gardener
2021-01-04 10:55   ` Ole-Hjalmar Kristensen
2021-01-04 11:03     ` hiro
2021-01-04 19:08       ` joe
2021-01-04 20:44         ` hiro
2021-01-04 21:01         ` ori
2021-01-05  3:41 ` Joe S
2021-01-05  9:40   ` hiro
2021-01-06 22:21   ` [9fans] " cigar562hfsp952fans
2021-01-07  8:06     ` hiro
2021-01-07 16:02   ` [9fans] " ori
2021-01-25 22:31 ` David Arroyo
2021-01-27 16:25   ` Ethan Gardener
2021-01-27 16:52   ` ori
2021-01-27 17:34     ` Charles Forsyth
2021-01-28  0:17     ` David Arroyo [this message]

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=829ad45b-941b-46f9-acef-7eddf541104f@www.fastmail.com \
    --to=droyo@aqwari.net \
    --cc=9fans@9fans.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).