| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2020-08-27 | |||
| 03:16:56 | brinzhang_ | s/save/safe | |
| 03:17:42 | chenke | #info chenke | |
| 03:18:22 | swp20 | xinranwang__: your format of test result is good enough. | |
| 03:18:48 | brinzhang_ | xinranwang_: not exactly all, we shoul keep the readable of the result, so the format shuold be beautiful ASAP | |
| 03:19:11 | Yumeng | xinranwang__: about the template, I'm fine with the structure of your report. I think that make sense to showt the report results and provision results | |
| 03:19:33 | xinranwang__ | I remember it was a website call paste.openstack.org, things like that. | |
| 03:19:44 | Yumeng | xinranwang__: just one small question, we can add openstack accelerator device list to show the report result in cyborg side. | |
| 03:19:47 | xinranwang__ | does anyone know that website> | |
| 03:20:11 | brinzhang_ | xinranwang_: paste.openstack.org is also a temparory place too | |
| 03:21:02 | brinzhang_ | I am trend to use wiki | |
| 03:21:09 | xinranwang__ | brinzhang_: does everyone can modify it? | |
| 03:21:19 | Yumeng | brinzhang_, xinranwang__: I also have the concern that etherpad and paste.openstack.org are temparory. anyobe can modify it | |
| 03:21:19 | xinranwang__ | Yumeng: ok, sure | |
| 03:22:15 | brinzhang_ | xinranwang_: no, but it will be lost with a long time | |
| 03:22:31 | xinranwang__ | brinzhang_: ok, got it. | |
| 03:22:59 | Yumeng | we can create a wiki page to record the driver report result and then add the link to the driver-support table on doc page https://docs.openstack.org/cyborg/latest/reference/support-matrix.html#driver-support | |
| 03:23:00 | xinranwang__ | It seems a wiki page is the better one | |
| 03:23:05 | Yumeng | what do you think? | |
| 03:23:05 | brinzhang_ | we can use wiki, but how do we let the user or operator know the result exist in wiki? | |
| 03:23:37 | xinranwang__ | We can mention this wiki page in cyborg doc | |
| 03:24:50 | brinzhang_ | agree, and we can add a column as "temparory result", marked when it merged | |
| 03:24:58 | shaohe_feng | the https://docs.openstack.org/cyborg/latest/reference/support-matrix.html#driver-support should add item to show the link | |
| 03:25:05 | shaohe_feng | yes | |
| 03:25:11 | Yumeng | yes, agree | |
| 03:25:44 | brinzhang_ | such as, Added it in Victoria (Auguest, 2020) | |
| 03:26:06 | Yumeng | yes, we can do that. | |
| 03:26:11 | brinzhang_ | and past the wiki test result link | |
| 03:26:16 | xinranwang__ | lol, like a biography for the driver | |
| 03:27:13 | Yumeng | yep =_< | |
| 03:27:23 | brinzhang_ | ok, let do it by this way, after meeting, I will send an email to the ML, that everyone should do, if they are not have the third-party CI | |
| 03:27:33 | swp20 | aggree | |
| 03:28:00 | Yumeng | brinzhang_: cool. | |
| 03:28:46 | Yumeng | about the driver implementation, I have another quesion to discuss | |
| 03:29:02 | Yumeng | VENDOR_MAPS format of GPU,FPGA are different, should we keep consistent? | |
| 03:29:30 | Yumeng | FPGA is like this https://github.com/openstack/cyborg/blob/master/cyborg/accelerator/drivers/fpga/base.py#L23 | |
| 03:29:45 | Yumeng | while GPU is like https://github.com/openstack/cyborg/blob/master/cyborg/accelerator/drivers/gpu/base.py#L26 | |
| 03:30:38 | swp20 | we can merge them in one dict. | |
| 03:31:04 | brinzhang_ | move this to a common file? | |
| 03:32:18 | xinranwang__ | Yumeng: what do you mean by difference | |
| 03:32:22 | brinzhang_ | VENDER_MAPS = ['GPU': {'0x8086': 'intel', ..}, 'FPGA': {'','', ...}] | |
| 03:32:46 | brinzhang_ | how about like this? that we can maintain this in one place | |
| 03:34:06 | xinranwang__ | Just wondering why we should do this. Is there any gap in current implementation? | |
| 03:34:40 | brinzhang_ | not array, a dict. VENDER_MAPS = {'GPU': {'0x8086': 'intel', ..}, 'FPGA': {'','', ...}} | |
| 03:36:27 | brinzhang_ | xinranwang_: I am not sure what Yumeng want todo, but from the maintain accelerator devices type and vendor, that we can merge this, because we can easy to know what devices that we can support | |
| 03:37:28 | brinzhang_ | but as you said, is it make sense? It make sense to me. ^ | |
| 03:38:00 | Yumeng | xinranwang__: initially, this is a downstream problem I found in baremetal support. ironic report Nvidia GPU vendor_id as hexadecimal int, while we accept vendor_id as string | |
| 03:38:40 | xinranwang__ | brinzhang_: https://github.com/openstack/cyborg/blob/cde5c3421d03722696269eb45ac148afd9838042/cyborg/common/constants.py#L90 we can this to show all supported resources. | |
| 03:38:49 | Yumeng | here by difference I mean '0x8086' and '10de' | |
| 03:38:55 | xinranwang__ | Yumeng: ok, that's the problem. | |
| 03:39:42 | xinranwang__ | It comes from the discovery method. Intel drivers all discover devices from sysfs which contains the hex number. | |
| 03:39:59 | Yumeng | seems different, I not yet look into the details. | |
| 03:40:29 | Yumeng | but should we keep consistent, or just let this go and let any driver do their own way | |
| 03:40:49 | xinranwang__ | AFAIK, the gpu driver's result comes from lspci's output. | |
| 03:41:06 | swp20 | Inspur FPGA is '1db4' like GPU. | |
| 03:41:09 | Yumeng | yes | |
| 03:41:20 | swp20 | yeah also use lscpi command. | |
| 03:42:07 | xinranwang__ | So the problem is that if driver use lspci, the output is now in hex format. We may need to translate it. | |
| 03:42:47 | Yumeng | sounds good. | |
| 03:43:28 | Yumeng | we can rethink it and make decision later. not in a hurry. | |
| 03:43:49 | xinranwang__ | Yes, we should leave some time to program api discussion. | |
| 03:43:56 | xinranwang__ | ;) | |
| 03:44:34 | brinzhang_ | do we need to maintain a list for the supported device type? we know every product maybe need a driver | |
| 03:44:50 | Yumeng | YES, We don't have much time left, I wanna leave some time for haibin-huang s_shogo, and shaohe_feng to discuss Program API | |
| 03:45:11 | s_shogo | yes, that's welcome >> Program API discussion | |
| 03:45:35 | shaohe_feng | hello | |
| 03:45:43 | haibin-huang | ok | |
| 03:46:03 | haibin-huang | hello shogo | |
| 03:46:12 | s_shogo | hello haibin-huang | |
| 03:46:58 | s_shogo | Is ok to begin discussion about the program API? | |
| 03:47:22 | haibin-huang | yes | |
| 03:47:27 | s_shogo | Thanks, | |
| 03:48:04 | haibin-huang | so, what is your question? | |
| 03:48:07 | s_shogo | haibin-huang , shaohe, xinran : Let me confirm, what type FPGA do you use for the test of programming API?(N3000?) | |
| 03:48:42 | s_shogo | IMHO, in my concern, to use N3000 with Cyborg, that needs suited driver for N3000 and async program algorithm for that, before trying programming API. | |
| 03:49:30 | haibin-huang | yes, N3000 | |
| 03:49:43 | shaohe_feng | we need aysnc | |
| 03:50:04 | shaohe_feng | s/aysnc/async | |
| 03:51:23 | s_shogo | OK,t I got it. | |
| 03:52:26 | s_shogo | As we discussed in previous IRC, I thinks that needs new driver and async, and that seems to be out of scope of this Program API patch.. | |
| 03:52:42 | haibin-huang | I think we should consider two points, one is reboot fpga, one is get program status | |
| 03:52:48 | s_shogo | Are there any plan for modifying driver and cyborg mechanism for N3000? | |
| 03:55:36 | haibin-huang | we have implentation draft for it | |
| 03:55:56 | haibin-huang | but, we don't know when we can push is upstream | |
| 03:57:03 | haibin-huang | the Draft is not ready to push it upstream | |
| 03:58:23 | s_shogo | Ok, I got it. | |
| 03:58:43 | s_shogo | So that is better to be reviewed as the target. | |
| 03:58:53 | s_shogo | Of course, the programming method for N3000 is important,that should be discussed as another patch and IRC. | |
| 04:00:04 | s_shogo | I would like to settle out the program patch work as current scope, once. | |
| 04:01:27 | shaohe_feng | OK, but can you add a new API for program status check, just add a UnimplemenationExcetpion(" unsport") ? | |
| 04:01:43 | shaohe_feng | just define the API | |
| 04:02:03 | shaohe_feng | we can add a the implementation later. | |
| 04:03:16 | s_shogo | umm, to add a new API for program check is agree, | |
| 04:06:51 | shaohe_feng | OK, thanks | |
| 04:08:38 | s_shogo | Thanks, shaohe-feng :) | |
| 04:09:12 | Yumeng | s_shogo，shaohe_feng：cool. since we don't have much time left for victoria, I think we should keep the scope of program API patch focused. and add other features later. | |
| 04:09:45 | s_shogo | Yumeng Thanks, I agree that. | |
| 04:10:17 | Yumeng | Thanks haibin-huang for coming to join the discussion. | |
| 04:10:37 | s_shogo | Thanks haibin-huang, shaohe-feng | |
| 04:11:04 | Yumeng | Thanks s_shogo and shaohe_feng, program API is not easy work. | |
| 04:12:18 | Yumeng | time is up for today. I will bring up the left topics(PTG things) on wechat where necessary | |