| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-05-28 | |||
| 14:45:22 | shaohe_feng | good, expect it. Thanks. | |
| 14:46:05 | shaohe_feng | If no more, we can end the meeting. | |
| 14:49:36 | shaohe_feng | #endmeeting | |
| 14:49:38 | openstack | Meeting ended Mon May 28 14:49:36 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 14:49:39 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg_driver/2018/openstack_cyborg_driver.2018-05-28-14.02.html | |
| 14:49:40 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg_driver/2018/openstack_cyborg_driver.2018-05-28-14.02.txt | |
| 14:49:41 | openstack | Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg_driver/2018/openstack_cyborg_driver.2018-05-28-14.02.log.html | |
| 15:04:14 | openstackgerrit | Li Liu proposed openstack/cyborg master: Added cyborg fpga programming spec https://review.openstack.org/559395 | |
| #openstack-cyborg - 2018-05-29 | |||
| 12:50:21 | openstackgerrit | wangzhh proposed openstack/cyborg master: Load cyborg-api app with paste_deploy https://review.openstack.org/570931 | |
| 16:34:46 | openstackgerrit | ShaoHe Feng proposed openstack/cyborg master: doc fix: devstack setup doc can not display well https://review.openstack.org/570968 | |
| 17:07:00 | openstackgerrit | Li Liu proposed openstack/cyborg master: Added cyborg fpga programming spec https://review.openstack.org/559395 | |
| #openstack-cyborg - 2018-05-30 | |||
| 02:11:27 | openstackgerrit | Li Liu proposed openstack/cyborg master: Added cyborg fpga programming spec https://review.openstack.org/559395 | |
| 07:59:04 | shaohe_feng | zhipengh[m], I have update the wiki https://wiki.openstack.org/wiki/Cyborg#How_to_contribute | |
| 07:59:33 | shaohe_feng | add DevStack Quick Start link to the wiki | |
| 08:00:25 | shaohe_feng | so New contributors can follow it setup their cyborg env. | |
| 08:01:14 | shaohe_feng | Any issue during the setup, they can fix it and feedback to community. | |
| 09:24:11 | openstackgerrit | Merged openstack/cyborg master: doc fix: devstack setup doc can not display well https://review.openstack.org/570968 | |
| 09:25:50 | openstackgerrit | wangzhh proposed openstack/cyborg master: Load cyborg-api app with paste_deploy https://review.openstack.org/570931 | |
| 09:39:25 | openstackgerrit | wangzhh proposed openstack/cyborg master: Load cyborg-api app with paste_deploy https://review.openstack.org/570931 | |
| 14:03:08 | Sundar | #info Sundar | |
| 14:09:30 | sum12 | no meeting today ? | |
| 14:10:10 | Li_Liu | still waiting for Howard | |
| 14:10:44 | Li_Liu | shaohe_feng can you start the meeting for us? | |
| 14:10:56 | Li_Liu | in case Howard is in middle of something\ | |
| 14:11:28 | Sundar | The meeting topic is set to 'spec review day'. Was that announced earlier? | |
| 14:12:19 | Li_Liu | I think that is for a few week earlier | |
| 14:14:19 | shaohe_feng | Li_Liu, hello | |
| 14:15:12 | Li_Liu | let start the meeting shaohe_feng | |
| 14:15:46 | shaohe_feng | #startmeeting openstack-cyborg | |
| 14:16:02 | shaohe_feng | #topic Roll Call | |
| 14:16:16 | Sundar | #info Sundar | |
| 14:16:17 | shaohe_feng | #info shaohe_feng | |
| 14:16:39 | Li_Liu | #info Li_Liu | |
| 14:17:31 | Li_Liu | #topic summit summary | |
| 14:17:39 | Li_Liu | am I doing it right? | |
| 14:17:55 | Li_Liu | changing the topic | |
| 14:18:02 | shaohe_feng | yes. | |
| 14:18:33 | shaohe_feng | welcome Li_Liu introduce his experience during summit. | |
| 14:18:58 | Li_Liu | ok, a few of us went to the summit last week. Welcome to Canada for those of you who came | |
| 14:19:30 | Li_Liu | We had a few talks given regarding to Cyborg | |
| 14:20:22 | Li_Liu | I gave a Cyborg project update. Friends from Lenovo gave a demo using Cyborg to manage GPUs in their ThinkCloud product | |
| 14:20:56 | Li_Liu | JF. Ding also gave a talk with 99 cloud folks, which involves cyborg a lot | |
| 14:21:29 | Li_Liu | the general feedback is great. A lot of attentions are coming the way to Cyborg | |
| 14:21:40 | shaohe_feng | good. | |
| 14:22:06 | Li_Liu | couple quick comments from the audiences | |
| 14:22:40 | sum12 | any recurring comments ? | |
| 14:23:23 | Li_Liu | 1. Managing GPUs is still not a killer app for Cyborg. Prob showing other capabilities on top of this might draw more attentions | |
| 14:25:12 | Li_Liu | 2. In order to become a strong piece of OpenStack or even addition to k8s in the future, we need to push the development further and faster | |
| 14:25:36 | Li_Liu | as we are actually facing competitions from the Nova vGPU management. | |
| 14:26:09 | Li_Liu | currently we are at pretty much the same stage as them. | |
| 14:27:28 | Li_Liu | some people are looking at us since they think currently vGPU management in Nova should just be temperate. | |
| 14:28:14 | Li_Liu | They believe once Cyborg becomes more mature, it should be the one actually solve the general problem | |
| 14:28:32 | Li_Liu | This is from me. | |
| 14:28:41 | Li_Liu | anyone else has anything to share? | |
| 14:29:24 | Sundar | I moderated a session on Cyborg/FPGA in Cloud/NFV. | |
| 14:29:56 | shaohe_feng | Sundar, can you give a summary about it? | |
| 14:30:04 | Sundar | It was meant for discussion with operators and end users. We had Verizon, SKA and CERN there, apart from many developers, incl. Nova developers | |
| 14:30:35 | Sundar | The discusison is here: #link https://etherpad.openstack.org/p/Cyborg-FPGA-Support-for-Cloud-NFV | |
| 14:31:14 | Sundar | One of the main conclusions is that the model where VM issues programming requests (what we called run-time programming) is important | |
| 14:31:27 | Sundar | However, we do not have a good end-to-end flow for that today. | |
| 14:31:44 | Sundar | This is an open question that we should address. | |
| 14:32:11 | Li_Liu | The main concern is who to trigger the programming right? | |
| 14:32:57 | Sundar | That is one of the main concerns, the other being the validity of the bitstream itself | |
| 14:33:11 | Li_Liu | ah, that one | |
| 14:34:15 | Sundar | For example, if a developer is developing new RTL inside the VM, the resulting bitstream may have bugs. Can that compromise the shell logic? Can it result in local hot spots or other power issues that affect the FPGA chip itself? | |
| 14:35:06 | Sundar | I was hoping to get feedback from operators on how they plan to validate bitstreams. Has Huawei considered that question? | |
| 14:35:45 | Li_Liu | in terms of operation, shall we 1. let this rtl be synthesis in a wel controlled environment. 2. Let this bitstream load on a clean room enviroment first | |
| 14:36:07 | Li_Liu | actually, internally, we did have some discussion | |
| 14:36:57 | Li_Liu | for now, we might not care too much about it as most of the IPs are in house developed | |
| 14:37:18 | Li_Liu | but in the case of letting 3rd party do the development | |
| 14:37:41 | Li_Liu | I think at lease 1. let this rtl be synthesis in a well controlled environment. is needed | |
| 14:38:49 | Sundar | If the environment is well-controlled, the bitstream may still have bugs. So, it is necessary but not sufficient. | |
| 14:40:17 | Sundar | Re. "Let this bitstream load on a clean room enviroment first", that is a good idea. So, do we confine bitstream development to bare-metal instances, so that a tenant can affect only himself or the local FPGA? | |
| 14:40:27 | Li_Liu | yes, that's why the 2nd point is also needed | |
| 14:41:46 | Li_Liu | it depends, it might just be a VM with a entire bitstream. The cloud provider should provide a CI/CD framework for such dev work | |
| 14:41:57 | Li_Liu | entire FPGA sorry :( | |
| 14:42:38 | Sundar | Sure. By clean room environment, do you mean bare-metal instances for development? | |
| 14:44:20 | shaohe_feng | Li_Liu, do you means is a VM just own a region, it does not be allowed to do program except it own the whole FPGA? | |
| 14:44:33 | Li_Liu | hmm, IMO developer/user might not even care/sense this. All they care is I submit my rtl and it passed all the sanity test | |
| 14:45:01 | Li_Liu | shaohe_feng we are not there yet | |
| 14:46:24 | Li_Liu | after the sanity test, the synthesized bitstream is allowed to be loaded on the PR/FPGA | |
| 14:47:58 | Sundar | What is the sanity test? Checking for power issues depends on workloads and dynamic conditions | |
| 14:50:03 | Li_Liu | Sundar, as least the sanity test should check the rlt for security concerns | |
| 14:50:46 | shaohe_feng | Sundar, Li_Liu, the scenario, a tenant by a VM from cloud provider, he want this VM as his development evn, which means he will do his RTL iterative development in this VM | |
| 14:50:51 | Li_Liu | to identify any malicious behavior | |
| 14:52:29 | shaohe_feng | so there will be error during his development. | |
| 14:53:19 | Li_Liu | shaohe_feng, I agree. | |
| 14:54:57 | Li_Liu | Cloud might also want to provide Synthesis as a Service/Sanity Test as a Service | |
| 14:55:36 | Li_Liu | this we all the bitstream that are being loaded on the FPGA are gated by these services | |
| 14:56:23 | shaohe_feng | yes. | |
| 14:59:14 | Li_Liu | I am not sure if Synthesis as a Service/Sanity Test as a Service will be in the Cyborg Scope. But I think all the cloud operator should definitely consider them | |
| 14:59:56 | shaohe_feng | Sundar, what's your opinion? | |
| 15:01:22 | Sundar | Yes, cloud operators need to do 'something'. That often runs into conflict with two things: (a) bitstream developers often want confidentiality, (b) it is tough to take a bitstream (or even a post-fit netlist) and check whether it is 'good' | |
| 15:01:56 | Sundar | I suspect there is no silver bullet, and the answer will be some combination of technology and business practices | |
| 15:02:57 | Sundar | Anyways, the other big question was: how does the VM initiate programming? | |
| 15:03:54 | Li_Liu | I agree, point b is rather complicated. | |
| 15:04:12 | shaohe_feng | Sundar, does the user need to push his image to glance, let cyborg do the program or he do the program in his local VM? | |
| 15:04:20 | Li_Liu | currently, our in house implementation is using REST calls | |
| 15:04:35 | Li_Liu | to call the reprogramming service api | |
| 15:04:44 | Sundar | One way is to let the VM have access to programming the FPGA directly. Another way is to have the VM generate the request and let it come to Cyborg. There are 2 ways to do that, both with pros and cons. | |