On Mittwoch, 13. Juli 2022 11:19:48 CEST Christian Schoenebeck wrote:

On Dienstag, 12. Juli 2022 23:11:42 CEST Dominique Martinet wrote:

quoted

Dominique Martinet wrote on Wed, Jul 13, 2022 at 04:33:35AM +0900:

quoted

Christian Schoenebeck wrote on Tue, Jul 12, 2022 at 04:31:36PM +0200:

quoted

So far 'msize' was simply used for all 9p message types, which is far
too much and slowed down performance tremendously with large values
for user configurable 'msize' option.

Let's stop this waste by using the new p9_msg_buf_size() function for
allocating more appropriate, smaller buffers according to what is
actually sent over the wire.

Only exception: RDMA transport is currently excluded from this, as
it would not cope with it. [1]

Thinking back on RDMA:
- vs. one or two buffers as discussed in another thread, rdma will still
require two buffers, we post the receive buffer before sending as we
could otherwise be raced (reply from server during the time it'd take to
recycle the send buffer)
In practice the recv buffers should act liks a fifo and we might be able
to post the buffer we're about to send for recv before sending it and it
shouldn't be overwritten until it's sent, but that doesn't look quite
good.

- for this particular patch, we can still allocate smaller short buffers
for requests, so we should probably keep tsize to 0.
rsize there really isn't much we can do without a protocol change
though...

Good to know! I don't have any RDMA setup here to test, so I rely on what
you say and adjust this in v6 accordingly, along with the strcmp -> flag
change of course.

As this flag is going to be very RDMA-transport specific, I'm still
scratching my head for a good name though.

Or, instead of inventing some exotic flag name, maybe introducing an enum for 
the individual 9p transport types?
 
Best regards,
Christian Schoenebeck