Earlier  
Later
New Search
Posted Nick Remark
#openstack-cyborg - 2020-08-27
03:14:53 xinranwang__ do we have a template wiki to show test result?
03:15:52 brinzhang_ xinranwant_: may we should have to create a tempate for this
03:16:42 brinzhang_ the etherpad is not save, because it can be modified by everyone
03:16:50 xinranwang__ IMO, the format of test result is not a big deal. Just to show the driver works.
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 xinranwang__ Yumeng: ok, sure
03:21:19 Yumeng brinzhang_, xinranwang__: I also have the concern that etherpad and paste.openstack.org are temparory. anyobe can modify it
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 brinzhang_ we can use wiki, but how do we let the user or operator know the result exist in wiki?
03:23:05 Yumeng what do you think?
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.

Earlier   Later