https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-2379 Lustre <p>Warpmech got LNet performance issue over 40GigE:</p> <ul> <li>between two 40GigE nodes, selftest can only get half of bandwidth <ul> <li>it's not a big surprise to me, because socklnd connection is bound with exact one thread, and receiving side doesn't have Zero-copy, which means only one core is receiving from a 40GigE link if there is only one peer, so I suspect performance of 1:1 40GigE is CPU bound.</li> <li>one possible solution is reusing CONTROL link to transfer bulk data as well with some special policy</li> <li>I know that enable kiov vmap can help on receiving performance of some NICs, but not sure it will work for this case.</li> </ul> </li> <li>while running BRW tests between 10GigE clients and 40GigE server, one direction can work well (saturate the bandwidth), another direction can only get half. <ul> <li>8 clients read can saturate the link pretty well, but I don't know if 4 clients can do the same.</li> <li>8 clients write can't saturate the link, it can get half of bandwidth. I actually found that one 10GigE client can only get 250-300MB/sec on write against 40GigE server, which matches aggregation write performance of 8 clients (2GB/sec)</li> <li>network latency is quite low (I don't remember the number)</li> </ul> </li> </ul> LU-2379

40GigE LNet performance

Improvement Major Resolved Cannot Reproduce WC Triage Liang Zhen Fri, 23 Nov 2012 00:45:34 +0000 Thu, 11 Jun 2020 09:52:13 +0000 Thu, 11 Jun 2020 09:52:13 +0000 0 9 <p>1. point to point 40GE tests:<br/> I heard that at least a fully utilized 5GHz CPU would be needed to saturate one direction of a 10GE link, if nothing is off loaded from host CPU. That depends on message size. Have they tuned jumbo frames and TCP send/recv buffers?</p> <p>2. BRW tests between 10GigE clients and 40GigE server:</p> <p>I assumed that it was 8 clients vs one server. If true, then when 8 clients are reading, the overhead of memory copying on incoming data was spread over the 8 clients, while in the write case, the server had to handle all the memory copy overhead. If that's the cause, then it'd be interesting to see the results with more servers, e.g. 8 clients write to 2 servers or more.</p> Development Rank 1|hzvcpj: Rank (Obsolete) 5648