我理解uadk对标的是openssl 1. 性能不能弱于openssl, 比如小包不能被openssl 吊打，不然客户没理由花钱换uadk，结果性能还降了
2. 可以参考openssl 增加engine/provider，就是按照要求写个模块， 不需要加一个加速器 框架里面还得到处加代码。
ps: 奇怪这个邮件进入spam, 都没发现。
On Thu, 23 Jan 2025 at 16:17, liulongfang liulongfang@huawei.com wrote:
-----邮件原件----- 发件人: Zhangfei Gao [mailto:zhangfei.gao@linaro.org] 发送时间: 2025年1月22日 15:47 收件人: fanghao (A) fanghao11@huawei.com; liulongfang liulongfang@huawei.com; song.zhiqi77@qq.com; shenyang (M) shenyang39@huawei.com; Chao Xie chao.xie@linaro.org; Kaly XIN kaly.xin@linaro.org; qianweili qianweili@huawei.com 抄送: acc@openeuler.org 主题: 1.22 会议 follow up
- longfang 问的ctx的问题
adapter 方案 ctx 是在worker 内部的，每个worker有pool, ctx 等资源，完全解耦/不相关的 比如sve 是支持异步的， hw+sve 异步是完全没问题的，
代码 wd_cipher_init2_ for (i = 0; i < adapter->workers_nb; i++) { // 依次初始化各worker wd_alg_attrs_init(worker, &wd_cipher_init_attrs); switch (driver_type) { case UADK_ALG_SVE_INSTR: 分配sve的ctxs // sve, ce 其实可以合并 case UADK_ALG_HW: 分配hw的ctx
wd_cipher_common_init ->wd_init_async_request_pool(&worker->pool, // 分配worker自己的pool }
另外，adapter方案的调度是选择worker, 是以worker为调度单元 比如小包 sw，大包 hw，
我们之前的调度，是期望每次过来能选择不同的ctx， 实际中多线程需要加锁，性能跟不上，所以被废弃掉了。 直接改成了alloc_sess的时候就绑定ctx，即每个线程就指定一个ctx 我理解这个其实就是ctx_allocator
adapter 方案是把ctx 封装到worker内部了，即只管怎么选worker, 如果是硬件，还是按现在这样，绑定ctx的 目前get_worker 选择worker 是放在算法层
- To longfang
之前想到的问题, 在群里也提过
前提是如果用户初始化的时候init(mix) 指定了选择异构调度， a, 这个代码不好改，比如已经上传了dpdk/ceph社区 b. 即使能改，init 很费时间，uadk_engine 基本是初始化的时候就init 了， 即 init 一旦选择了异构调度方案 就不会随便动了。
------>直接用旧的调度模式，改进异构调度框架之后，旧的这些场景保持旧的配置参数不变就行
1） 流模式下，不能运行一半发生切换，如何避免 即调度器如何知道 现在是不是流模式，算法层的信息如何传递给调度层。
------>流模式就用流模式的调度模式，原始的RR调度，纯粹的HW处理。因为流模式无法切换设备进行完整计算
在什么地方配置流模式的调度模式，动态配置还是啥 流模式配置完，什么时候配置回来？
一共有多少个调度模式？ 哪里配置，init2的时候配置还是啥，代码有么？
ps. adapter 方案是在 算法层做的，所以直接就能判断是否是流模式
- 如何实现threshold, 很多场景就只是小包，无论怎么优化，就是指令集快
调度器如何知道包的大小，需要传给调度层
------> 小包场景就指定适配小包场景的调度器，不需要修改API层框架，兼容适配方便。
在什么地方配置适配小包场景的调度器，一开始就配置还是动态配置 配置完小包场景，进来大包如何处理。
ps. adapter 方案是在 算法层，直接获取包的大小，这个数据结构各算法还不一样 比如req->src_len vs req->in_bytes
------> 是的，你的adapter写在API层，可以直接获取，缺点就是所有的调度方案都需要在API层修改代码，场景多起来之后API层会非常臃肿
就一个函数get_worker，
- 硬件出错怎么处理，fb 异步能否实现，fb方案其实我们没验证过。
------> 异步场景的fb依旧是软算的同步模式完成处理，不涉及fb内部的异步 代码 cipher.c wd_do_cipher_async msg_id = wd_get_msg_from_pool(&wd_cipher_setting.pool, idx, (void **)&msg); //ctx_id a
drv: temp_msg = wd_cipher_get_msg(qp->q_info.idx, tag); // ctx_id_a
如果fb-> drv_b temp_msg = wd_cipher_get_msg(ctx_id_b, tag); // 这里我理解拿不到msg, 可能有坑 ------>不需要这样处理，fb中只跑同步。用户不关注你的fb中跑什么模式。
不清楚，没仔细考虑这个方案，也没验证过， 一个方案里面套了另一个方案，有点复杂了。 觉得还不如不支持，让用户自己调用软算处理。
ps：adapter方案 的做法是设标记，上层retry进来选worker[1]
- 多个加速器，如何选, hw/ce/sve
龙芳群里的回答： 指定业务运行方式，配置设备驱动 不懂 目前的做法 删掉ce的库，然后指定sve ------> init2接口中有配置参数，业务类型，调度器类型参数，队列配置参数配置。通过这些配置可以选择运行场景
sve, ce 区分不了， 都是一个类型，instr 未来如果有 sve2， sme 都是instr，估计还得删。
ps：adapter方案 可以在uadk.conf 配置， 通过命令行 也可以 即生成个配置文件 /tmp/pid.conf， setenv
- 不同平台加速器不一样，920 hw, 920b hw/ce/sve, 920c? 一套模式/算法在一个平台上调好，其他平台是否适用
龙芳群里的回答：自动适配，不区分硬件平台 ------>是的，不区分硬件平台，差异由用户态驱动自己适配，用户层面不感知硬件差异。
不同算法，比如rsa，cipher/digest 行为模式不一样，同一套策略可能不适应。
不同算法可能有区别 比如rsa 就是硬件好 cipher/digest 就是小包指令集更好。
- 未来如果有办法读取带宽，能否/怎么支持。
这个龙芳群里回答过 带宽查询功能具备以后，通过驱动的get_usage()直接读取，然后再新建一个调度器根据设备利用率实施调度 ------>是的，用户态驱动在ops设计时有设计这个功能，可以实际适配使用。
ps：adapter方案 可能做法是get_worker里面加if/else
【腾讯文档】adapter方案 https://docs.qq.com/doc/DRUxFaVJDdHJFUWdM _______________________________________________ Acc mailing list -- acc@openeuler.org To unsubscribe send an email to acc-leave@openeuler.org