-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support keep alive in spdk tcp backend #462
Comments
Hi @LiadOz, thanks for putting this on our radar. We will have to spend some time coming up with the optimal solution. |
This would technically work as a workaround. If |
@karlowich This solution seems to work for my use case. In my fork I added |
@LiadOz as you point out in your previous comment But maybe I'm missing something? |
|
@LiadOz Yes, but as far as I can tell, if you don't plan on calling |
I'm saying that the parameter In addition, when this value is set in the spdk of the host side, when So with the solution you suggested, since I can't call |
@LiadOz Sorry, you are absolutely right. Now I see the value of being able to set |
@LiadOz Can I close this? |
My PR only added the option to enable the keep alive feature. The way we are sending the keep alive commands is workaround/hack, I don't think this ticket should be closed until a proper solution for it is implemented. But if you think the current workaround is good enough you can close this ticket. I have no problem with continuing to work with the hack. |
@LiadOz Good point, let's keep this open to remind us in the future. |
According to NVMe TCP Transport Specification 2021.06.02
We have encountered the need for keep alive timeout in our application in a case of a sudden shutdown. The shutdown caused the host to abort the commands, but the target has kept them until it was brought back a few minutes later, after that time commands that were sent before the shutdown were completed without the application knowing about them causing data integrity issues. Had a keep alive been active, the target would have aborted those commands.
In
lib/xnvme_be_spdk_dev.c
the keep_alive_timeout_ms option is disabled for transport types TCP and RDMA, and it seems that this had existed since the spdk backend was created.Allowing the user to specify a keep alive timeout is not enough, here is how that keep alive should be used according to spdk:
So to fully support the feature, either xNVMe needs to create a thread that polls
spdk_nvme_ctrlr_process_admin_completions
or give the user the ability to call that function on their own.The text was updated successfully, but these errors were encountered: