lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 13 Jul 2022 11:29:13 +0200 From: Christian Schoenebeck <linux_oss@...debyte.com> To: Dominique Martinet <asmadeus@...ewreck.org> Cc: Latchesar Ionkov <lucho@...kov.net>, Eric Van Hensbergen <ericvh@...il.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, v9fs-developer@...ts.sourceforge.net, Nikolay Kichukov <nikolay@...um.net> Subject: Re: [V9fs-developer] [PATCH v5 11/11] net/9p: allocate appropriate reduced message buffers On Mittwoch, 13. Juli 2022 11:19:48 CEST Christian Schoenebeck wrote: > On Dienstag, 12. Juli 2022 23:11:42 CEST Dominique Martinet wrote: > > Dominique Martinet wrote on Wed, Jul 13, 2022 at 04:33:35AM +0900: > > > Christian Schoenebeck wrote on Tue, Jul 12, 2022 at 04:31:36PM +0200: > > > > 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
Powered by blists - more mailing lists