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

Adapter 5.25 #557

Open
wants to merge 10 commits into
base: master
Choose a base branch
from
Open

Adapter 5.25 #557

wants to merge 10 commits into from

Conversation

gaozhangfei
Copy link
Collaborator

No description provided.

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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Will use hisi_zlib to test adapter, so let UADK_ALG_SOFT register to uadk

Signed-off-by: Zhangfei Gao <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
}
}

/* fixme, how to ensure send and recv are matched in async mode */
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are several issues that need to be analyzed:

  1. Adapter scheduling in asynchronous mode cannot currently match.
  2. The current adapter’s driver scheduling can only implement the RR scheduling algorithm.
  3. In a UADK framework, there are two levels of scheduling (ctx
    scheduler and driver adapter) are unreasonable and should be fused

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are several issues that need to be analyzed:

  1. Adapter scheduling in asynchronous mode cannot currently match.
    Do you mean one transaction is split into several times, some use opsA, some use opsB?
  1. 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.
  1. 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.

Copy link
Collaborator

@Liulongfang Liulongfang Nov 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are several issues that need to be analyzed:

  1. 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.

  1. 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

  1. 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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are several issues that need to be analyzed:

  1. 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.

  1. 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

  1. 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.

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.

3 participants