deserialization module optimization #331
Conversation
|
@nlgwcy: The label(s) In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/status in-progress |
nlgwcy
changed the title
| @@ -590,7 +595,7 @@ int deserial_update_elem(void *key, void *value) | |||
|
|
|||
| ret = get_map_fd_info(id, &map_fd, &info); | |||
| if (ret < 0) { | |||
| LOG_ERR("invlid MAP_ID: %d\n", id); | |||
| LOG_ERR("invlid MAP_ID: %d, errno:%d\n", id, errno); | |||
There was a problem hiding this comment.
| LOG_ERR("invlid MAP_ID: %d, errno:%d\n", id, errno); | |
| LOG_ERR("invlid MAP_ID: %d, get map failed:%d\n", id, errno); |
I'm not sure what fd means, representing the actual operation in the logs allows for a better understanding of the error
nlgwcy
changed the title
| The current implementation scheme is as follows: | ||
|
|
||
| - Bitmap is used to manage which inner_map records are free, and the bitmap information is stored in the first record of the outter_map. | ||
| - During xDS configuration creation, the outter_map is searched for a `idle`idx, and the corresponding inner_map is created. The inner_map information is added to the outter_map table, and the bitmap information is updated as `used`(the outter_map table is also updated). |
There was a problem hiding this comment.
outter_map size is 8192 , and i believe it is not enough, As we can see there are almost 8192/100+1 threads to do some initiaztion work. How can we adapt to the size increase later
There was a problem hiding this comment.
in Risks and Mitigations section, possible solution are mentioned, and can be tracked in #330
|
|
||
| As we can see, one xDS change involves multiple outter_map refreshes. Here is the optimization approach (space-time trade-off): | ||
|
|
||
| - When kmesh-daemon starts, create all outter_map records (including inner_map) at once, using multiple threads to parallelize the refresh process since the outter_map table updates slowly. |
There was a problem hiding this comment.
why does outter_map table update slowly? Is this because BPF_MAP_TYPE_ARRAY_OF_MAPS
There was a problem hiding this comment.
yes, kernel has set synchronization operations in this PR and has been updated in the docs.
Signed-off-by: wuchangye <wuchangye@huawei.com>
Signed-off-by: wuchangye <wuchangye@huawei.com>
Signed-off-by: wuchangye <wuchangye@huawei.com>
Signed-off-by: wuchangye <wuchangye@huawei.com>
| printf("inner_map_create %d failed:%d\n", i, fd); | ||
| } | ||
| if (i < MAX_OUTTER_MAP_ENTRIES) | ||
| LOG_WARN("[warning]inner_map_create (%d->%d) failed:%d, errno:%d\n", i, MAX_OUTTER_MAP_ENTRIES, fd, errno); |
There was a problem hiding this comment.
donot we need to return erro nunber? ANd what will happend if later we need to r/w on the map
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hzxuzhonghu The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind cleanup
/kind enhancement
/kind documentation
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?: