quoted

quoted

quoted

quoted

quoted

I've looked again at the code, and I'm not convinced that the patch
is needed at all anymore, I'm now surprised that it actually changed
anything (disregarding data digest).

The driver does not track the received bytes by definition, it relies
on the controller to send it a completion, or set the success flag in
the _last_ c2hdata pdu. Does your target set
NVME_TCP_F_DATA_SUCCESS on any of the c2hdata pdus?

Perhaps you can also run this patch instead?

Thanks, will give this a shot.

Still would be beneficial to look at the traces and check if
the success flag happens to be set. If this flag is set, the
driver _will_ complete the request without checking the bytes
received thus far (similar to how pci and rdma don't and can't
check dma byte count).

I realized this patch is the same as one you'd sent earlier. We hit the
BUG_ON(), and then proceeded to use your follow-up patch, which appeared
to fix the data receive problem, but introduced data digest problems.

So, are you saying that hitting this BUG_ON means that the driver has
observed the completion out-of-order from the expected data?

If you hit the BUG_ON it means that the host spotted a c2hdata
PDU that has the success flag set before all the request data
was received:
--

@@ -759,6 +761,7 @@ static int nvme_tcp_recv_data(struct nvme_tcp_queue

*queue, struct sk_buff *skb,
                        queue->ddgst_remaining = NVME_TCP_DIGEST_LENGTH;
                } else {
                        if (pdu->hdr.flags & NVME_TCP_F_DATA_SUCCESS) {
+                               BUG_ON(req->data_received != req->data_len);
                                nvme_tcp_end_request(rq, NVME_SC_SUCCESS);
                                queue->nr_cqe++;
                        }
--