| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2019-10-17 | |||
| 03:18:27 | Sundar | So, Yumeng and all, please review it. | |
| 03:18:49 | xinranwang | can we get bug fix patch in now, as the doc patch ;) | |
| 03:19:09 | Yumeng | ok, will do. | |
| 03:19:24 | chenke | Done. | |
| 03:19:48 | Sundar | Nope :( There was lots of resistance to backporting other patches. We can potentially do a point-release early in U if we really want, IMO, all that is beside the point till we get nova integ. | |
| 03:20:18 | Sundar | Once we get nova integ done, we have the option of doing an early point release instead of waiting for April/May | |
| 03:20:52 | Sundar | Basically, non-doc patches require version change. | |
| 03:21:09 | xinranwang | ok, got it. | |
| 03:21:43 | xinranwang | now the doc patch review has high priority. | |
| 03:22:01 | Sundar | Yes. | |
| 03:22:15 | xinranwang | when is the ddl for doc patches? | |
| 03:23:02 | Sundar | No deadline. Train is more or less done. So, we can backport any time | |
| 03:24:36 | Sundar | BTW, Cyborg got some free press in OpenStack press releases: https://www.zdnet.com/article/the-openstack-train-keeps-chugging-on/, https://www.theregister.co.uk/2019/10/15/openstack_train/ | |
| 03:24:44 | Sundar | Kudos to all of you :) | |
| 03:25:30 | Sundar | In other news, Nova-Cyborg interaction spec (https://review.opendev.org/#/c/684151/) got +2 from Nova PTL. Need to follow up more. | |
| 03:26:11 | xinranwang | good news! | |
| 03:26:17 | chenke | Great | |
| 03:26:29 | chenke | will follow up. | |
| 03:27:52 | Sundar | The press articles sound a bit weak because they mentioned only the Nova spec merge. We haven't really claimed that Cyborg supports VM creation etc. in this release. The next release is going to dleiver the goods, and we should be able to make stringer statements. | |
| 03:28:03 | Sundar | *stronger | |
| 03:28:20 | chenke | Ye. | |
| 03:28:44 | Sundar | #topic AoB | |
| 03:28:50 | chenke | Cyborg is a popular project for openstack. | |
| 03:29:00 | Sundar | Yes | |
| 03:29:03 | Sundar | Anything else for today? | |
| 03:29:25 | chenke | I want to confirm that the version has been sent out. Does it make sense to change the documentation? | |
| 03:30:02 | Sundar | Are you asking if it is ok to change the docs after Train has shipped? | |
| 03:30:04 | chenke | If users take the version, they won't get the latest documents | |
| 03:30:33 | Sundar | Hmm, if they clone stable/train in the future, after we merge the doc patches, they will get them all. | |
| 03:30:33 | chenke | Has the train been sent out? | |
| 03:31:09 | chenke | Yes. If they clone the stable/train , they will get them. | |
| 03:31:15 | Sundar | More or less: https://review.opendev.org/#/c/687991/ has bene merged | |
| 03:31:53 | Sundar | I think they have some backend work. It should be done by this week, I think | |
| 03:32:31 | shaohe_feng | Will this release add more ACC support? | |
| 03:32:49 | Sundar | Do you mean if we get more drivers in U? | |
| 03:32:49 | shaohe_feng | another questions. | |
| 03:32:54 | shaohe_feng | yes. | |
| 03:33:02 | shaohe_feng | more drivers? | |
| 03:33:10 | shaohe_feng | any plane for it? | |
| 03:34:16 | shaohe_feng | Do we support apply FPGA pf to a VM? | |
| 03:34:36 | Sundar | We could. We need to talk about it. Right now, we got some drivers for GPU and Ascend. However, the maintainers are not regularly participating in Cyborg activities. That makes me concerned about maintenance. Also, we don;t have 3rd party CI for any driver yet. We are planning that for FPGAs, but what about other drivers? | |
| 03:35:01 | Sundar | I was replying about drivers, not PF | |
| 03:35:27 | shaohe_feng | so the questions is that. | |
| 03:35:43 | shaohe_feng | If a end user apply a FPGA | |
| 03:35:43 | Sundar | As a team, we may have to decide on a higher bar for drivers. That is something we can discuss here on at the PTG. | |
| 03:35:45 | Sundar | *or | |
| 03:35:56 | shaohe_feng | I will not attend PTG. | |
| 03:36:29 | Sundar | Ah yes, too bad. You can give your ideas here or in the PTG etherpad. | |
| 03:36:30 | shaohe_feng | if he found there's bug on his bitstream? | |
| 03:36:50 | shaohe_feng | what should he do? | |
| 03:37:06 | shaohe_feng | delete the VM, rebuild a new VM with a FPGA? | |
| 03:37:14 | Sundar | Passing a FPGA PF to a VM is potential security hole, because we don;t know what bitstreams get programmed | |
| 03:37:14 | s_shogo | Wow, it's so good > CI for FPGA driver's. | |
| 03:37:22 | shaohe_feng | or just re-program it? | |
| 03:38:21 | Sundar | We have a usage model called Runtime Programming, which we don't support today. It involves VM issuing requests for new bitstreams, Cyborg or something receives that request and does the reprogramming. We don;t see many customers asking for that | |
| 03:38:42 | shaohe_feng | maybe, the end user after doing his AI, then he want to change the AI model, which means he maybe need a new bitstream for his AI net model. | |
| 03:38:48 | shaohe_feng | what should he do? | |
| 03:39:16 | xinranwang | I think we can provider a program interface for this kind of users. | |
| 03:39:25 | xinranwang | in vf use case. | |
| 03:39:44 | Sundar | He could get the VM to issue a request somehow to underlying infra. That is not there today. Today, he only needs to stop that VM and start a new one | |
| 03:40:13 | Sundar | xinranwang: User cannot reprogram a FPGA via VF. | |
| 03:40:59 | shaohe_feng | yes, but he take a great effort to setup his AI env, such as install the openvino and the dependency, set connection with the camera maybe. | |
| 03:41:07 | xinranwang | if boot with bit-stream failed, vm should become failed. if user boot a vm successfully, and want reprogram the FPGA, what will we do. | |
| 03:41:27 | shaohe_feng | so should should delete vm, rebuild one, and take effort to setup the env again? | |
| 03:42:58 | shaohe_feng | Seams now, the user just can use FPGA as fix function PCI devices once he create the VM | |
| 03:43:29 | Sundar | If there is a strong customer demand for that, have that customer(s) call Intel. This use case will require changes in the product level, software stack and in Cyborg. It will also require discussion among ourselves in Cyborg community. | |
| 03:44:21 | shaohe_feng | I did not seen the flexible advantage of FPGA. | |
| 03:44:44 | xinranwang | hat is a problem. | |
| 03:44:52 | xinranwang | * That | |
| 03:45:09 | Sundar | There are different usage models of FPGA. Many customers are adopting it with the current software stack. | |
| 03:45:21 | Sundar | Perhaps we can take this offline, rather than hold everybody up. | |
| 03:45:22 | shaohe_feng | the question is that, cyborg is not adopt in a product at present. So we miss so many customer demand for end user. | |
| 03:45:23 | xinranwang | IMHO, Cyborg should support reprogram right? | |
| 03:45:53 | Sundar | xinranwang: It should and it does today (at least will after Nova integ). | |
| 03:46:59 | xinranwang | Sundar: Yes, so I think it is doable for user who want update their bitstream. | |
| 03:47:28 | shaohe_feng | so I should tell the user who wants to try cyborg, that we will not support reprogram, right? | |
| 03:48:29 | s_shogo | In my case,the current PAC seems to have some constraints (ex necessary for disabling SR-IOV when programming) and that is problem for reprogram in our usecase. | |
| 03:48:32 | Sundar | shaohe_feng: Why do you say that? We can reprogram when a VM is being launched. We cannot reprogram after a VM is launched. Most users today need only the former, from what we have seen. | |
| 03:48:36 | s_shogo | I would like to discuss these constraints are temporary or not, and cyborg( and user ) should think them as premise or not,in PTG and so on. | |
| 03:49:25 | Sundar | s_shogo: Sure, I;ll add usage models as a topic at the PTG, and come with some slides explaining our thoughts/plans. | |
| 03:49:48 | s_shogo | Great, thanks > Sundar | |
| 03:49:55 | shaohe_feng | Sundar, just think you want to do a AI with FPGA. you want to try you different model to find the best solution, what you should do? | |
| 03:50:30 | shaohe_feng | You can can add the reprogram in the etherpad list. | |
| 03:50:58 | shaohe_feng | and involve more end users to discuss it during PTG. | |
| 03:51:05 | Sundar | General question to all: s_shogo, chenke, Yumeng, shaohe_feng, xinranwang: Are you interested in FPGAs with networking? Adding that will require further discussion. We started that at the beginning of Train, but didn't follow u. | |
| 03:51:26 | Sundar | s/u./up./ | |
| 03:52:03 | Sundar | It will require Cyborg-Neutron interaction. I have some ideas for that, but they haven't been discussed deeply with neutron community yet. | |
| 03:52:30 | xinranwang | s_shogo: Could you list the constraints you met in etherpad? | |
| 03:53:10 | s_shogo | I have great interest in networking with FPGA, as a telco-carrier. ut there is not clear demand for interaction with neutron. | |
| 03:53:23 | s_shogo | s/ut/but/ | |
| 03:54:19 | shaohe_feng | I have looked into OVS card base FPGA before. | |
| 03:54:21 | s_shogo | xinranwang: ok, I'll list the constraints in etherpad, it may include misunderstanding, pointing out is welcome and happy for me :) | |
| 03:54:28 | shaohe_feng | it can works with DPDK. | |
| 03:54:28 | Sundar | s_shogo: The question is, does the networking solution require basic resources like MAC/IP addresses, and more advanced things like security groups and VXLAN config? These things are best left to neutron, rather than Cyborg replicating them. | |
| 03:55:39 | xinranwang | s_shogo: thanks, I am willing to see it. We can check if we also met them :P | |
| 03:56:47 | Sundar | OK, anything else for today? | |
| 03:57:45 | Yumeng | Sundar: Yes, I have intrests in smart NICs network adapter base FPGA, things like that. | |
| 03:57:53 | Yumeng | nothing else. thanks! | |
| 03:58:07 | Sundar | Great. Glad to hear the widespread interest. | |
| 03:58:27 | s_shogo | The current application in networking in FPGA is limited, so these parameters could be applied via application or operation. | |