On Wed, May 15, 2019 at 12:28:20PM +0100, Andrea Bolognani wrote: > On Wed, 2019-05-15 at 12:14 +0100, Dave Martin wrote: > > On Wed, May 15, 2019 at 09:03:58AM +0100, Andrea Bolognani wrote: > > > On Tue, 2019-05-14 at 13:14 -0700, Richard Henderson wrote: > > > > Why is =4 less user-friendly than =512? > > > > > > > > I don't actually see "total bits in vector" as more user-friendly than > > > > "number > > > > of quadwords" when it comes to non-powers-of-2 like =7 vs =896 or =13 > > > > vs =1664. > > > > > > I would wager most people are intimately familiar with bits, bytes > > > and multiples due to having to work with them daily. Quadwords, not > > > so much. > > > > Generally I tend to agree. For kvmtool I leaned torward quadwords > > purely because > > > > 16,32,48,64,80,96,112,128,144,160,176,192,208 > > > > is a big pain to type compared with > > > > 1,2,3,4,5,6,7,8,9,10,11,12,13 > > > > Even though I prefer to specify vector lengths in bytes everywhere else > > in the Linux user API (precisely to avoid the confusion you object to). > > > > This isn't finalised yet for kvmtool -- I need to rework the patches > > and may not include it at all initially: kvmtool doesn't support > > migration, which is the main usecase for being able to specify an exact > > set of vector lengths AFAICT. > > > > Since this is otherwise only useful for migration, experimentation or > > machine-driven configuration, a bitmask > > > > 0x1fff > > > > as some have suggested may well be a pragmatic alternative for kvmtool. > > Just to be clear, I have suggested using bits (or bytes or megabytes > depending on the exact value) only for the command-line-user-oriented > sve-vl-max option, which would take a single value. > > For interoperation with the management layer, on the other hand, > using a bitmap is perfectly fine, and whether the values encoded > within are expressed in quadwords or whatever other format is largely > irrelevant, so long as it it's properly documented of course.
Seems fair. Cheers ---Dave
