Adapter 5.25 #557
Adapter 5.25 #557
Conversation
c554ad8
to
17547a0
Compare
17547a0
to
729a852
Compare
Add wd_find_drv to find drv with drv_name and alg_name, considering several drivers supporting same alg. Also add UADK_ALG_ADAPT to compat with init2 interface Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Interface: uadk_adapter_alloc; uadk_adapter_free; uadk_adapter_set_mode; uadk_adapter_attach_worker; uadk_adapter_parse; uadk_adapter_config Supported mode: round-robin, threshold Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
In order to simulate cpu instruction accelerator, this patch adds zlib drv, which does not require accelerator at all. So may not require wd_xxx_init, and ctx and sched which relates to queue. Btw, zlib is required. apt-get install zlib1g-dev Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Will use hisi_zlib to test adapter, so let UADK_ALG_SOFT register to uadk Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Threshold mode need get msg length from msg, and compare length with threhold to decide using hardware or software accelerator. However msg struct are not same. Hack move length to the head of msg. Hack with digest, cipher, aead: in_bytess struct wd_rsa_req: __u32 src_bytes struct wd_ecc_req: __u32 src_bytes struct wd_dh_msg: ? struct wd_comp_msg: __u32 in_cons? Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
init interface switch to adapter init2 interface use adapter for MIX mode Test: uadk_tool test --m sec --digest 0 --sync --optype 0 --pktlen 16 \ --keylen 16 --times 1 --multi 1 uadk_tool test --m sec --digest 0 --sync --optype 0 --pktlen 16 \ --keylen 16 --times 1 --multi 1 --init 2 Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Switch to adapter interface via init2 interface Test: uadk_tool benchmark --alg zlib --mode sva --opt 0 --sync --pktlen 1024 \ --seconds 1 --multi 1 --thread 1 Test only hisi_zlib only hisi_zip Both hisi_zlib and hisi_zip, using round-robin as default mode. Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
driver can only update length msg->produced = msg->req.dst_len - strm.avail_out; msg->in_cons = msg->req.src_len; status is decided by caller // not sure about this patch, with this patch, compress and decompress are both OK ./sample/uadk_comp --optype 0 --alg gzip <src >out ./sample/uadk_comp --optype 1 --alg gzip <out >dst vimdiff src dst Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
switch to init2 interface, which use adapter
Test:
func()
{
uadk_comp --optype 0 --alg $1 <src >out
uadk_comp --optype 1 --alg $1 <out >dst
vimdiff dst src
}
func gzip
func zlib
Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
use hisi_zip if >= threshold use hisi_zlib if < threshold Test: uadk_tool benchmark --alg zlib --mode sva --opt 0 --sync \ --pktlen 1024 --seconds 1 --multi 1 --thread 1 uadk_tool benchmark --alg zlib --mode sva --opt 0 --sync \ --pktlen 10240 --seconds 1 --multi 1 --thread 1 Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
729a852
to
ea08f0c
Compare
| } | ||
| } | ||
|
|
||
| /* fixme, how to ensure send and recv are matched in async mode */ |
There was a problem hiding this comment.
There are several issues that need to be analyzed:
- Adapter scheduling in asynchronous mode cannot currently match.
- The current adapter’s driver scheduling can only implement the RR scheduling algorithm.
- In a UADK framework, there are two levels of scheduling (ctx
scheduler and driver adapter) are unreasonable and should be fused
There was a problem hiding this comment.
There are several issues that need to be analyzed:
- Adapter scheduling in asynchronous mode cannot currently match.
Do you mean one transaction is split into several times, some use opsA, some use opsB?
- The current adapter’s driver scheduling can only implement the RR scheduling algorithm.
Have realized threshold policy, but need to get packet size, via changing the struct.
- In a UADK framework, there are two levels of scheduling (ctx
scheduler and driver adapter) are unreasonable and should be fused
They are different thing, adapter only choose ops, ie, choose driver.
The ctx is hardware resource, I think it likes memory, alloc and free, no need schedule.
Anyway, it's better to split.
There was a problem hiding this comment.
There are several issues that need to be analyzed:
- Adapter scheduling in asynchronous mode cannot currently match.
Do you mean one transaction is split into several times, some use opsA, some use opsB?
No. What I mean is that currently only synchronous mode is implemented in the adapter code.
In asynchronous mode, if multiple drivers are supported at the same time. It may not be possible to recycle the message.
- The current adapter’s driver scheduling can only implement the RR scheduling algorithm.
Have realized threshold policy, but need to get packet size, via changing the struct.
If the adapter needs to actually implement software and hardware multiple drivers to send and receive messages in a mixed manner. It needs to support the device corresponding to the driver to obtain the device load in real time. Send messages based on load data
- In a UADK framework, there are two levels of scheduling (ctx
scheduler and driver adapter) are unreasonable and should be fused
They are different thing, adapter only choose ops, ie, choose driver.
The ctx is hardware resource, I think it likes memory, alloc and free, no need schedule.
Anyway, it's better to split.
My point of view is exactly the opposite of yours. ctx is allocated from the device, and the driver is also matched one-to-one with the device. Therefore, after ctx is determined, the corresponding device is also determined. At the same time, the driver must also be determined. Therefore, when the scheduler schedules ctx, it actually completes the driver selection. Therefore, the functions of the adapter can be merged into the scheduler.
There was a problem hiding this comment.
There are several issues that need to be analyzed:
- Adapter scheduling in asynchronous mode cannot currently match.
Do you mean one transaction is split into several times, some use opsA, some use opsB?No. What I mean is that currently only synchronous mode is implemented in the adapter code. In asynchronous mode, if multiple drivers are supported at the same time. It may not be possible to recycle the message.
- The current adapter’s driver scheduling can only implement the RR scheduling algorithm.
Have realized threshold policy, but need to get packet size, via changing the struct.If the adapter needs to actually implement software and hardware multiple drivers to send and receive messages in a mixed manner. It needs to support the device corresponding to the driver to obtain the device load in real time. Send messages based on load data
- In a UADK framework, there are two levels of scheduling (ctx
scheduler and driver adapter) are unreasonable and should be fused
They are different thing, adapter only choose ops, ie, choose driver.
The ctx is hardware resource, I think it likes memory, alloc and free, no need schedule.
Anyway, it's better to split.My point of view is exactly the opposite of yours. ctx is allocated from the device, and the driver is also matched one-to-one with the device. Therefore, after ctx is determined, the corresponding device is also determined. At the same time, the driver must also be determined. Therefore, when the scheduler schedules ctx, it actually completes the driver selection. Therefore, the functions of the adapter can be merged into the scheduler.
For example, the data is coming, big packet goto hardware, small packet goto sw/cpu instruction.
But we don't know the data is big or small in the beginning, so can not decide at first.
Let's discuss in the meetting with Chinese to be more clear.
No description provided.