Repository navigation
Conversation
| UCP_EP_FLAG_FAILED | | ||
| UCP_EP_FLAG_CLOSED)) { |
There was a problem hiding this comment.
aren't we already setting "level" based on error handling mode?
or the point of the PR is avoiding "req->status = status" so close_nb request will not fail?
There was a problem hiding this comment.
or the point of the PR is avoiding "req->status = status" so close_nb request will not fail?
yes, the point of this PR is to not set req->status to the error
aren't we already setting "level" based on error handling mode?
when it fails:
(gdb) p req->send.ep->worker->ep_config[req->send.ep->cfg_index]->key.err_mode
$2 = UCP_ERR_HANDLING_MODE_NONE
the peer failure wasn't requested by the test, but UCP unconditionally provides error callback to UCT
Line 1197 in c197746
There was a problem hiding this comment.
the peer failure wasn't requested by the test, but UCP unconditionally provides error callback to UCT
it's ok to provide callback to UCT. as long as we don't call user callback from UCP.
In this case, the test should suppress log message. It should not expect "silent" error, when ucp ep err mode is not set.
There was a problem hiding this comment.
it's ok to provide callback to UCT. as long as we don't call user callback from UCP.
yes, I know
In this case, the test should suppress log message. It should not expect "silent" error, when ucp ep err mode is not set.
I guess, we should fix all tests that do disconnect
but what should we do with close request status? ignore the status?
There was a problem hiding this comment.
also, we should not fail the close request if the UCP's ucp_worker_iface_error_handler() was called, but its scheduled on progress part (ucp_worker_iface_err_handle_progress()) was not completed yet.
There was a problem hiding this comment.
i think this is actually TCP issue. the test should not generate error at all.
it happens because sometimes the receiver does not get notification about remote connection close, so when it creates 2nd connection, it picks a "zombie" connection from conn_match
There was a problem hiding this comment.
it happens because sometimes the receiver does not get notification about remote connection close, so when it creates 2nd connection, it picks a "zombie" connection from conn_match
it may not get a remote connection close, but since we always increment connection match ID, when we create new connection, it will try to find remote peer with new ID
There was a problem hiding this comment.
we didn't increment it on receiver side so it stayed with 0
There was a problem hiding this comment.
we didn't increment it on receiver side so it stayed with 0
do you mean that TCP EP lives for some time on a receiver side after its connection pair was disconnected, and then it fails and calls error handling callback?
a0cf6f9 to
3050ee4
Compare
3050ee4 to
032a688
Compare
|
bot:pipe:retest |
What
Fix handling of error in flush if EP failed.
Why ?
If EP failed and UCT iface ops are replaced by the
return UCS_ERR_ENDPOINT_TIMEOUT, it could fail flush in close operation.It starts failing after removing FAILED flag check in flush - #5952
Fixes #5977
How ?
Check if EP failed and is being closed by the user, just return w/o reporting any errors.