On 7/8/2021 3:24 PM, sweetpotatopie2021 (sweetpotatopie2...@protonmail.com) wrote: > Thes list showed one user (John at IBM) who reported success and transfer > rates of 7Gb/s. Without these patches I can get 200Mb/s max.
I suspect the 7Gb/sec throughput John observed is cumulative across a large number of simultaneous RPCs issued by many client systems not throughput for a single client's communication with a single fileserver. The patch series improves cumulative performance by permitting network traffic from clients A, B and C to potentially be serviced by a distinct rx_Listener (aka data pump) thread. It also reduces the overhead for sending and receiving rx packets by using sendmmsg() and recvmmsg() to batch transfer Rx packets on Linux / Solaris kernels which support them. These changes are also specific to Rx in userland such as a fileserver, volserver or database server; kernel Rx implementations are still limited to a single Rx listener and a single rpc worker thread. I'm pointing these details out because the changes are unlikely to improve performance of a single client reading / writing from a single fileserver. In that scenario all of the traffic from the client will be processed by a single rx listener thread. The bulk reading and writing of packets will change the performance of the link. Whether its an improvement or not depends upon a number of factors. One reason performance might drop for a single client with this series is that the batch reading/writing of packets combined with the sorting of read packets will adversely impact the ACK clock and could increase the likelihood that packets will be dropped when writing to a congested link. What is the scenario in which the 200Mb/sec transfer rate is observed and how is it measured? Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
