On Mon, Feb 22, 2021 at 05:36:17PM +0200, Gal Pressman wrote: > "Mellanox HCAs keep track of the last index for which the user received an > event. Using this index, it is guaranteed that an event is generated immediately > when a request completion notification is performed and a CQE has already been > reported." I don't think verbs exposes this behavior. > This also sounds weird, why is an event generated for a completion that has > already been reported? It eleminates races, if the consumer says 'I read up to X send me an interrupt if X+1 exists' when X+1 already exists if there is a race producer has already written it. So send an interrupt. > So from my understanding of how this should work, the following code in perftest > (ib_send_bw test) is buggy?: > https://github.com/linux-rdma/perftest/blob/master/src/perftest_resources.c#L2955 > > Running this with 32 iterations, the client does something like: > - arm cq > - post send x 32 > - wait for cq event > - arm cq > - poll cq (once, with batch size of 16) > - no more post send (reached tot_iters) > - wait for cq event (but an event has already been generated?) I don't know much about perf-test, but in verbs arming a non-empty CQ is asking for trouble Jason
