Am 01/06/2023 um 10:34 schrieb Fiona Ebner: > Am 31.05.23 um 16:34 schrieb DERUMIER, Alexandre: >> Le mercredi 31 mai 2023 à 13:36 +0200, Fiona Ebner a écrit : >>> Am 22.05.23 um 12:25 schrieb Alexandre Derumier: >>>> In addition to theses model, I have enabled aes too. >>>> I think it's really important, because a lot of users use default >>>> values and have >>>> bad performance with ssl and other crypto stuffs. >>>> >>> >>> So there is the answer to my aes question :) But shouldn't we rather >>> set >>> it via the UI as a default than change the CPU definition itself? >>> That >>> feels cleaner as we'd not diverge from how they defined the ABI. >> >> I don't have looked pve-manager code yet, but do you think it's easy >> to auto enable/disable the aes flag in the grid when we choose theses >> models ? > > I also haven't looked at the code, but yeah, it is an issue that it's in > the advanced part and we shouldn't hide it from the user that it's on. > >> Maybe could it be better to have 2 differents models, with/without aes >> (like some qemu models versions like -IBRS, >> here we could have >> >> x86-64-v2 >> x86-64-v2-aes (default) >> x86-64-v3 >> x86-64-v3-aes > > That might work, but if we do that, please only in the UI. Also not > ideal, because how would interaction with the flag in the grid work? > E.g. don't show it, force it on if an -aes model is selected?
Please no, I would find it very odd to see a CPU model in the Web UI that doesn't exist in the API/Backend. > > Maybe the easiest would be to extract the aes flag out of the grid into > the non-advanced part? Yes, rather that – but possibly without the radio-group UI but simply a combobox with "Yes" <- default, "Auto (CPU model)" or "no" options _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
