| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-07-08 | |||
| 13:49:05 | gibi | huaqiang: based on the runway slot availabilty we could focus on that series in the next two weeks if Tony is also available | |
| 13:49:09 | gibi | huaqiang: and thanks :) | |
| 13:49:47 | huaqiang | gibi, you are welcome | |
| 13:51:20 | sean-k-mooney | huaqiang: is tony prc based or in the us by the way. just wondering is this is a good time slot for them or not. if they are in prc this is getting late right | |
| 13:51:56 | huaqiang | he is in PRC | |
| 13:52:20 | sean-k-mooney | cool good to know | |
| 13:53:16 | huaqiang | yes, it's a bit too late for him. | |
| 13:54:00 | huaqiang | sean-k-mooney: I wonder if my collegues have send the SST document links to you | |
| 13:54:01 | sean-k-mooney | ya that fine we can just sync with him on gerrit or early moring eu time /late us time | |
| 13:54:27 | sean-k-mooney | huaqiang: am i dont see it in my inbox | |
| 13:54:31 | huaqiang | I think Tony will see my message tomorrow | |
| 13:54:44 | sean-k-mooney | do you know who will send it? | |
| 13:54:47 | gibi | huaqiang: thanks | |
| 13:55:09 | huaqiang | we are not in a same mail loop, I think | |
| 13:55:37 | huaqiang | basically, SST-BF have a core mask, not every core could be set as high priority | |
| 13:55:44 | huaqiang | but SST-CP could | |
| 13:56:19 | huaqiang | user should call the Linux sysfs interface for which core is possible for high priority | |
| 13:56:27 | sean-k-mooney | huaqiang: just doing an @intel seach i dont have anything related to this topic in the last day or so. | |
| 13:56:35 | sean-k-mooney | huaqiang: yes | |
| 13:56:57 | sean-k-mooney | so for SST-BF is the core mask fixed in hardware or adjustable | |
| 13:57:24 | sean-k-mooney | for sst-cp we can sway which core to priortise for power delivery right using a mask | |
| 13:58:23 | sean-k-mooney | if the cores for SST-BF are fixed in hardware we need to ensure the cpu_dedicated_set and cpu_share_set are alinged to the hardware mask | |
| 13:58:28 | huaqiang | SST-BF core mask is fixed in hardware, and varies from chip to chip, even same CPU type | |
| 13:58:58 | huaqiang | SST-CP is configuable | |
| 13:59:18 | sean-k-mooney | ok so ya ooo would need to discover that as part of the inspection phase and setup the *_set accordingly for SST-BF | |
| 13:59:32 | huaqiang | yes, cpu_dedicated_mask must select from the SST-BF core mask | |
| 13:59:33 | sean-k-mooney | but for SST-CP we could do it the reverse way around | |
| 14:00:03 | sean-k-mooney | e.g we coudl rpogram the mask based on teh cpu_dedicated_set parmater | |
| 14:00:50 | huaqiang | yes, for SST-CP we can determine a core mask then set it to hardware | |
| 14:01:09 | sean-k-mooney | ill not that in the downstream BZ so that we know about this limitation when we start working on the ooo changes | |
| 14:01:13 | sean-k-mooney | *note | |
| 14:01:42 | sean-k-mooney | huaqiang: you would not happen to know how we lookup the hardware mask for SST-BF would you? | |
| 14:01:56 | sean-k-mooney | is it in /sys? or do we have to check an MSR | |
| 14:03:28 | huaqiang | user need to get the CPU base frequency from ‘/sys/bus/cpu/devices/cpuN/cpufreq/base_frequency’ | |
| 14:03:49 | huaqiang | high priority core will have a higher frequency value | |
| 14:04:17 | huaqiang | so kernel requires >=5.1 | |
| 14:04:25 | sean-k-mooney | ok so we have to compute it its not just listed | |
| 14:04:41 | sean-k-mooney | well they woudl only have different based_frequency if the polcy was enabled | |
| 14:04:47 | sean-k-mooney | by defualt they would all have the same | |
| 14:05:17 | sean-k-mooney | or are you saying when we turn this on in the bios they go to different base frequencies and we can select the frequency | |
| 14:05:18 | huaqiang | yes | |
| 14:05:48 | huaqiang | the unit of 'base_frequency' is Mhz, you just read the CPU frequency | |
| 14:06:19 | huaqiang | do you know, in new platform ,we have another SST | |
| 14:06:29 | huaqiang | the SST-TF (turbo frequency) | |
| 14:06:31 | sean-k-mooney | three are 4 | |
| 14:06:45 | sean-k-mooney | SST-BF adjust base frequency | |
| 14:07:05 | sean-k-mooney | SST-CP adjust the core priport for core power delivery | |
| 14:07:13 | huaqiang | which is better for create two groups of CPUs with high or low turbo frequency | |
| 14:07:26 | huaqiang | turbo frequency is commonly used | |
| 14:07:35 | sean-k-mooney | SST-PP disables cores/enables cores to make more power/theremals avilabel for other cores | |
| 14:07:50 | huaqiang | yes | |
| 14:08:02 | sean-k-mooney | and SST-TB i guess work like SST-BF but allwos different terbo frequecies | |
| 14:08:23 | huaqiang | correct | |
| 14:09:07 | huaqiang | they are enabled in different interfaces | |
| 14:09:43 | huaqiang | so I'd like to let the 3rd-part tool for enabling it | |
| 14:09:48 | sean-k-mooney | https://github.com/intel/CommsPowerManagement/blob/master/sst_bf.py has code for some of the flavor of SST | |
| 14:10:05 | huaqiang | it's for SST-BF | |
| 14:10:31 | sean-k-mooney | yes although i tought there was code maybe in andiffer file for the other ones | |
| 14:10:55 | huaqiang | I don't find it | |
| 14:11:45 | huaqiang | PP and BF are ready in the silicon of last year | |
| 14:12:10 | huaqiang | TF is new, it is enabled on this year's product | |
| 14:12:33 | sean-k-mooney | yep CP should be there too in existing silicon | |
| 14:12:38 | sean-k-mooney | https://github.com/intel/CommsPowerManagement/blob/97c151ac2649535ad0d51113883a96764d9c7b87/pwr/setup.py#L15 | |
| 14:12:40 | huaqiang | CP is also launched | |
| 14:12:42 | huaqiang | in last year | |
| 14:12:49 | huaqiang | yes | |
| 14:12:52 | sean-k-mooney | they reference SST-CP in the metadata | |
| 14:13:05 | openstackgerrit | Stephen Finucane proposed openstack/nova master: virt: Add 'context', drop 'network_info' parameters for 'unrescue' https://review.opendev.org/730382 | |
| 14:13:05 | sean-k-mooney | so i suspec ti senabled in one of the files | |
| 14:13:05 | openstackgerrit | Stephen Finucane proposed openstack/nova master: crypto: Add type hints https://review.opendev.org/739207 | |
| 14:13:06 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Split '_create_domain' function https://review.opendev.org/739208 | |
| 14:13:06 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Add vTPM config support https://review.opendev.org/739209 | |
| 14:13:07 | openstackgerrit | Stephen Finucane proposed openstack/nova master: scheduler: Request vTPM trait based on flavor or image https://review.opendev.org/739210 | |
| 14:13:07 | openstackgerrit | Stephen Finucane proposed openstack/nova master: crypto: Add support for creating, destroying vTPM secrets https://review.opendev.org/739211 | |
| 14:13:08 | openstackgerrit | Stephen Finucane proposed openstack/nova master: manager: Prevent compute startup on invalid vTPM config https://review.opendev.org/739212 | |
| 14:13:09 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add emulated TPM support to Nova https://review.opendev.org/631363 | |
| 14:13:09 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Add docs for vTPM support https://review.opendev.org/739213 | |
| 14:13:09 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add support for resize and cold migration of emulated TPM files https://review.opendev.org/639934 | |
| 14:13:10 | openstackgerrit | Stephen Finucane proposed openstack/nova master: utils: Move 'get_bdm_image_metadata' to nova.block_device https://review.opendev.org/739996 | |
| 14:14:22 | huaqiang | It's better to have them | |
| 14:17:48 | sean-k-mooney | i found this before https://github.com/intel/sst-bf-openstack-setup-automation which tries to automate it but it was not entirely trival to figure out what it was doing with our painstakingly reverse engienriing it | |
| 14:18:44 | sean-k-mooney | huaqiang: its currently the best reference i coudl find however | |
| 14:19:05 | sean-k-mooney | it also only really covers SST-BF | |
| 14:22:19 | alex_xu | gibi: tony su is on the same team with me | |
| 14:22:38 | huaqiang | sean-k-mooney, OVS is a good workload for BF | |
| 14:23:37 | sean-k-mooney | huaqiang: ovs-dpdk even more so because you can trivialy pin the PMDs | |
| 14:24:12 | sean-k-mooney | kernel ovs is tricker since some of the processing is also done in the vhost_threads wo ideally you want toes to also be on the high priority cores | |
| 14:24:48 | sean-k-mooney | thos are kernel thready however that are spawned in responce to qemu so im not sure its easy to do that | |
| 14:25:09 | alex_xu | gibi: oh...just saw huaqiang already help on that | |
| 14:25:12 | sean-k-mooney | for ovs-dpdk however all the packet procesing is done in the pmd so its easy to configure | |
| 14:28:29 | huaqiang | we can use mixed instance and dedicated cores for PMD threads, and shared cores for other threads, right | |
| 14:28:31 | huaqiang | ? | |
| 14:29:19 | gibi | alex_xu: yes, thanks | |
| 14:30:23 | huaqiang | Hie alex_xu, stephenfin, the mixed instance pathces are ready for next review, please review at your convenient time! | |
| 14:30:50 | alex_xu | huaqiang: got it! | |
| 14:31:01 | huaqiang | alex_xu thanks! | |
| 14:31:19 | alex_xu | np | |
| 14:40:14 | sean-k-mooney | huaqiang: partly yes but i dont belive the core affitiy we apply to the vm cpus applyse to the kernel thread spwaned by the vhost kernel module | |
| 14:40:46 | sean-k-mooney | the are not forked or spwaned from the process | |
| 14:41:16 | sean-k-mooney | so i would not assume any cgroup/taskset limits applied to the eumlator thread or to the vcpus would have any affect on where they run | |