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, [email protected] 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
