Skip to content
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

examples/kdigest: add AF_ALG hash example #335

Closed
wants to merge 1 commit into from

Conversation

ddiss
Copy link
Contributor

@ddiss ddiss commented Apr 29, 2021

When built with CONFIG_CRYPTO_USER_API_HASH enabled, Linux exposes a
socket based API for hashing data. When coupled with uring
IOSQE_IO_LINK, file hashing can be done in quite an efficient manner,
as demonstrated in this link-cp.c based example.

Signed-off-by: David Disseldorp ddiss@suse.de

When built with CONFIG_CRYPTO_USER_API_HASH enabled, Linux exposes a
socket based API for hashing data. When coupled with uring
IOSQE_IO_LINK, file hashing can be done in quite an efficient manner,
as demonstrated in this link-cp.c based example.

Signed-off-by: David Disseldorp <ddiss@suse.de>
@chrisvest
Copy link

Looks like the linked pairs be processed out of order, so the hash result is non-deterministic, no?

@ddiss
Copy link
Contributor Author

ddiss commented Apr 29, 2021

Looks like the linked pairs be processed out of order, so the hash result is non-deterministic, no?

Yes, you're right. I'll close this while I rework it. Setting QD to one would be the most obvious fix but will likely hurt performance...

@ddiss ddiss closed this Apr 29, 2021
@ddiss
Copy link
Contributor Author

ddiss commented Apr 29, 2021

I think flagging IOSQE_IO_DRAIN on the AF_ALG send I/O would be the simplest fix for hash ordering here... IIUC it'll still permit AF_ALG send and next-offset file read I/Os to run concurrently, but everything else will move in lock step.

@ddiss
Copy link
Contributor Author

ddiss commented Apr 29, 2021

I think flagging IOSQE_IO_DRAIN on the AF_ALG send I/O would be the simplest fix for hash ordering here... IIUC it'll still permit AF_ALG send and next-offset file read I/Os to run concurrently, but everything else will move in lock step.

Looks like my force push has blocked reopening here. Will submit this change as a new PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants