| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-05-02 | |||
| 14:11:18 | Li_Liu | #info Li_Liu | |
| 14:11:40 | Li_Liu | I didn't | |
| 14:11:46 | xinran_ | what mail | |
| 14:11:59 | sundar | Hi Li_Liu, can we chat a bit? | |
| 14:12:24 | jiapei | Good evening | |
| 14:12:26 | Li_Liu | sure | |
| 14:12:37 | zhipengh[m] | lol | |
| 14:12:38 | Li_Liu | you wanna chat here? | |
| 14:12:54 | Li_Liu | sundar | |
| 14:13:58 | zhipengh[m] | No meeting today , but feel free to chat :) | |
| 14:14:03 | sundar | Li_Liu: For the FPGA bitstreams, we plan to use Glance properties | |
| 14:14:40 | sundar | Your spec referes to a table. That is a table in Cyborg, right? | |
| 14:17:05 | sundar | The spec https://git.openstack.org/cgit/openstack/cyborg/commit/?id=f1355e51fe89021cdd27308829c333a98c14820b says: "For each metadata, it will be stored as a row in this Glance's image_properties in key-value pair format" | |
| 14:20:34 | Li_Liu | Sundar | |
| 14:20:50 | sundar | Hi Li_Liu | |
| 14:21:12 | Li_Liu | For the Glance properties. It's not a table in Cyborg | |
| 14:21:20 | Li_Liu | I am re-using the table in Glance | |
| 14:21:39 | sundar | Are you proposing to add it to Glance? | |
| 14:21:44 | Li_Liu | nope | |
| 14:22:02 | sundar | Cyborg can use glaceclient to create and query properties | |
| 14:22:07 | sundar | *glanceclient | |
| 14:22:15 | Li_Liu | I am just defining what should be in that table if it's meant for a bitstream | |
| 14:22:36 | sundar | If we propose a change to Glance, we should fly it by them. But, by using only the glanceclient, we should be ok | |
| 14:23:24 | Li_Liu | you are right | |
| 14:23:35 | sundar | Ok. Instead of phrasing it as rows in Glance, which is really Glance internals, we can say what properties we intend to create and query | |
| 14:23:35 | Li_Liu | We are not changing anything in the Glance space | |
| 14:24:05 | Li_Liu | hmm. ok I can make according changes | |
| 14:24:13 | sundar | Cool, thanks. | |
| 14:24:59 | sundar | Also, having fields for 'shell' makes me concerned. Today, we use shell. But there is no guarantee that all products tomorrow | |
| 14:25:07 | sundar | ... will also use a shell | |
| 14:25:34 | sundar | There are lots of FPGA products out there, and somebody may want to make a service out of them | |
| 14:28:30 | Li_Liu | but I think for at least Xilinx/Altera fpga, we are following such scheme | |
| 14:28:52 | Li_Liu | that field is also optional | |
| 14:29:09 | Li_Liu | user can totally ignore it | |
| 14:29:24 | sundar | There are plenty of Alter-based products out there that don;t use a shell. Same must be true of Xilinx too. We should not preclude them from being used in the cloud, by design | |
| 14:29:57 | sundar | The spec says: "Required shell bs-uuid for this bitstream" | |
| 14:30:27 | sundar | What we really need is 3 separate fields: shell, region type UUID, function type UUID. | |
| 14:30:33 | Li_Liu | oh, for that | |
| 14:31:03 | sundar | The shell ID is presumably used by the proposed API to update shell logic, presumably | |
| 14:31:18 | sundar | The region type UUID is what is matched by the bitstream. A bitstream is synthesized for a specific region type | |
| 14:31:20 | Li_Liu | I marked that filed as nullable=True. "Required shell bs-uuid for this bitstream" I mean if a shell is required for this bitstrea, | |
| 14:32:20 | sundar | OK, Thanks for clarifying that the shell-id is optional | |
| 14:32:40 | sundar | Can we add a region type UUID and a function type UUID also? | |
| 14:33:09 | sundar | We need region type for matching the bitstream to the region type | |
| 14:33:57 | shaohe | zhipengh[m]: Li_Liu: sundar: can cyborg manage MK-TME? https://en.wikichip.org/wiki/x86/tme | |
| 14:35:23 | sundar | ZHipeng: there are many aspects to MKTME (and SGX). Some are clearly within Cyborg's reach. For others, I need to investigate | |
| 14:36:45 | Li_Liu | sundar: the problem is where are these region types pointing to? | |
| 14:37:01 | Li_Liu | are they pointing to another bitstream image? | |
| 14:37:58 | sundar | Li_Liu: The current approach seems to assume a simple model of a shell and a single region within that. That may not remain true over time. We may want to support multiple regions in the same shell. Then, we need a separate region type UUID for each such region. When we synthesize a bitstream, its metadata would say which region type it was synthesized for | |
| 14:38:28 | sundar | Each bitstream corresponds to a single region type, so the metadata need only identify one region type UUID | |
| 14:38:59 | Li_Liu | I see you point. | |
| 14:39:19 | shaohe | zhipengh[m]: Li_Liu: sundar: For MKTME, the keyID is limitation. Cyborg can manage the keyID, for example, assign a keyID to a VM, and how multi-VM (belong to one tanent) share one keyID | |
| 14:40:41 | Li_Liu | as you said, the region type UUID is packed in bitstreams during sythesis, Cyborg shoud not care which specific region this bs is targeting | |
| 14:40:58 | Li_Liu | until the bs program driver would figure it out | |
| 14:41:29 | Li_Liu | let's say you have shell A with 2 region c and d | |
| 14:41:30 | zhipengh[m] | Is there a hardware for tme ? | |
| 14:41:46 | zhipengh[m] | From wiki it looks like an instruction set ? | |
| 14:42:00 | sundar | Zhipeng: are you propsoing to extend Cyborg to SGX/TME, outside of accelerators? | |
| 14:42:01 | Li_Liu | and you are loading bs B into Ac region | |
| 14:43:06 | zhipengh[m] | Nope | |
| 14:43:19 | zhipengh[m] | That's why I asked the question | |
| 14:43:35 | Li_Liu | Cyborg only needs to know I have a shell A some where and I am sending bs B to the coresponding host(that contains an A) | |
| 14:43:38 | sundar | Li_Liu: Cyborg needs to handle the use case where the flavor asks for a function ID and a product trait (e.g. Intel ARria 10). The scheduler picks up all the RPs with that trait, including regions of different types. Based on which region got selected, Cyborg would quey glance for a bitstream that has the function ID as its property, and also the same region type UUID as its property. | |
| 14:43:52 | Li_Liu | and the program driver will load the bs B into the right region | |
| 14:44:48 | sundar | Li_Liu: please look at the use cases I defined in the CYborg/Nova spec | |
| 14:46:52 | sundar | Zhipeng: yes, it is an instruction set, together with other hardware mechanisms. I am not aware of any device to handle it. | |
| 14:48:08 | sundar | Zhipeng: Sorry if I am vague: I don't know how much is publicly known already :) | |
| 14:48:10 | zhipengh[m] | Then that might be out of our scope | |
| 14:48:35 | zhipengh[m] | Understood :) | |
| 14:49:04 | sundar | Is anybody asking Cyborg to support it? If so, we can probably ask for time to investigate? | |
| 14:50:29 | Li_Liu | sundar, you are saying when user doesn't know which bs they are trying to load at first place. but trying to find a region first then map to a usable bs on that region | |
| 14:50:36 | Li_Liu | am I right? | |
| 14:52:53 | sundar | Li_Liu: Users will not know about shell in general. The operator can broadly define 2 kinds of flavors: A. Flavor asks for a specific region type and optionally a bitstream. We call this Device as a Service. Nova finds a region of that type, and Cyborg programs it, before the VM comes up. | |
| 14:53:27 | sundar | B. The flavor asks for a function ID and a device trait (e.g. Intel Arria 10), not a region type. Nova finds all devices of that type, which may contain different region types. | |
| 14:54:01 | sundar | We call this Accelerated Function as a Service. Intel is interested in both use cases (and their variants). | |
| 14:54:07 | Li_Liu | ah, I see | |
| 14:55:20 | Li_Liu | I can surely add those two. then the one who is uploading the bs needs to figure out all of these information then | |
| 14:56:18 | sundar | Li_Liu: yes. We can have an Cyborg API which accepts a bitstream, ensures required metadata, validates optional metadata and then uploads to Glance | |
| 14:57:53 | Li_Liu | Thanks a lot for the suggestions | |
| 14:58:11 | Li_Liu | so this meeting turns out to be a FFA discussion :) | |
| 14:58:31 | sundar | Li_Liu: FFA? | |
| 14:58:59 | Li_Liu | free for all | |
| 14:59:21 | sundar | lol, yes it was FFA | |
| 15:00:25 | sundar | Hope to make more discussions with you to make sure we are headed in the same direction :) | |
| 15:00:33 | sundar | *have more | |
| 15:00:55 | Li_Liu | sure anytime :) | |
| 15:02:10 | zhipengh[m] | EMFA | |
| 15:07:03 | shaohe | sundar: zhipengh[m]: Li_Liu: I means the KeyID management instead the TME, that libvirt's thing. | |
| 15:07:33 | shaohe | but keyID seems not a acceleration, but it is a resource. | |
| 15:15:08 | zhipengh[m] | Yes that would be problematic | |
| #openstack-cyborg - 2018-05-03 | |||
| 01:37:05 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: Introduce quota_usage and reservation table to Cyborg https://review.openstack.org/564968 | |
| 03:21:43 | openstackgerrit | Li Liu proposed openstack/cyborg master: Added bitstream metadata standardization spec https://review.openstack.org/558265 | |
| 06:24:57 | openstackgerrit | ShangXiao proposed openstack/cyborg master: Add documentation and release notes links to README https://review.openstack.org/565974 | |
| 09:34:31 | ildikov | zhipengh[m]: hi | |
| 09:34:51 | zhipengh[m] | Hey :) | |
| 09:35:47 | ildikov | zhipengh[m]: I pinged you as we have an Upstream Institute training in Vancouver right before the Summit | |
| 09:36:19 | ildikov | zhipengh[m]: and there are a few people interested in Cyborg and I was wondering whether you or anyone from the team arrives early enough to pop by on Sunday? | |
| 09:36:52 | ildikov | zhipengh[m]: the training is Saturday afternoon - Sunday all day, but we will not get to any project specific questions/topics on Saturday | |
| 09:39:36 | ildikov | zhipengh[m]: you can find info about the training here: https://docs.openstack.org/upstream-training/ and I'm also happy to answer any questions you have | |
| 09:51:29 | zhipengh[m] | ildikov: thx for the information, I myself won't be able to travel to Vancouver I'm afraid, but we have two core member attending, I will let them know about the upstream training :) | |