mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-25 21:54:06 +08:00
cbf1f9a46c
If the completer is in the middle of a large read operation, one lost packet can cause havoc. Going to COMPST_ERROR_RETRY will cause the requester to resend the request. After that, any packet from the first attempt still in the receive queue will be interpreted as an error, restarting the error/retry sequence. The transfer will quickly exhaust its retries. This behavior is very noticeable when doing 512KB reads on a QEMU system configured with 1500B MTU. Also, a resent request here will prompt the responder on the other side to immediately start resending, but the resent packets will get stuck in the already-loaded receive queue and will never be processed. Rather than erroring out every time an unexpected future packet arrives, just drop it. Eventually the retry timer will send a duplicate request; the completer will be able to make progress since the queue will start relatively empty. Signed-off-by: Andrew Boyer <andrew.boyer@dell.com> Signed-off-by: Doug Ledford <dledford@redhat.com> |
||
---|---|---|
.. | ||
Kconfig | ||
Makefile | ||
rxe_av.c | ||
rxe_comp.c | ||
rxe_cq.c | ||
rxe_dma.c | ||
rxe_hdr.h | ||
rxe_icrc.c | ||
rxe_loc.h | ||
rxe_mcast.c | ||
rxe_mmap.c | ||
rxe_mr.c | ||
rxe_net.c | ||
rxe_net.h | ||
rxe_opcode.c | ||
rxe_opcode.h | ||
rxe_param.h | ||
rxe_pool.c | ||
rxe_pool.h | ||
rxe_qp.c | ||
rxe_queue.c | ||
rxe_queue.h | ||
rxe_recv.c | ||
rxe_req.c | ||
rxe_resp.c | ||
rxe_srq.c | ||
rxe_sysfs.c | ||
rxe_task.c | ||
rxe_task.h | ||
rxe_verbs.c | ||
rxe_verbs.h | ||
rxe.c | ||
rxe.h |