03:13 <muurkha> sorear: servers that receive many requests from different clients can switch keys pretty fast, but in most cases the context where that matters most is initial authentication, before AES can be used

03:13 <muurkha> (because it's a DoS vector)

03:14 <sorear> don't think "14 KiB TLS segment", think "48 byte ATM cell"

03:15 <sorear> _maybe_ "576 byte IPv4 packet"

03:15 <muurkha> probably nobody has enough concurrent ssh connections for keystrokes to matter?

03:16 <wonty> i don't think people still care about ATM :-P

03:20 <sorear> in any event it's interesting that the affordance AES provides for storing the last KEYSIZE subkey bits, and then performing key expansion in _reverse_ to generate subkeys for decryption on the fly, seems to be completely unused by any higher level protocol or interface that I've ever seen

03:21 <wonty> ah, ATM forum became IP/MPLS which merged with the DSL Forum to become the Broadband forum. Yes, ATM is dead.

04:16 <Sofia> Hmm. Is the following understanding of RISC-V's vectors correct? The smallest implementation supports 128-bit registers, which may be grouped together up to 8x, resulting in 128 byte operations. Or is the register group size hardware defined too, whre the minimum group could be 1x? - Whereas a single AVX512 operation operates over 64-bytes.

04:17 <Sofia> where*

04:43 <sorear> I don't completely understand your phrasing, but all implementations are required to support all values of LMUL (1, 2, 4, and 8)

04:44 <sorear> the smallest implementation of "RISC-V vectors" has VLEN = 32, so LMUL=8 only gives you 256 bits, but the "V" abbreviation requires a minimum VLEN of 128

04:59 <sorear> "slides" makes me worry they're a bit old

06:05 <Sofia> sorear: These look like the slides. https://riscv.org/wp-content/uploads/2018/05/15.20-15.55-18.05.06.VEXT-bcn-v1.pdf

06:05 <Sofia> And this article seems to agree with the group logic. https://fprox.substack.com/p/risc-v-vector-register-groups

06:06 <sorear> that slidedeck is painfully pre-ratification, polymorphic encoding died a while ago and there are no ratified transcedentals

06:07 <sorear> https://github.com/riscv/riscv-v-spec/releases/download/v1.0/riscv-v-spec-1.0.pdf is the final ratified version

06:08 <Sofia> Right.

06:19 <Sofia> sorear: VLEN = 128, LMUL = 8 -> VLEN * LMUL minimum is 1024 bits = 128 bytes -> double avx512?

06:20 <sorear> i feel like there's a different question here that you aren't asking

06:21 <sorear> avx512 gives you 32 512b vregs + dedicated mask registers (I forget how many or how big), vlen=128 V is only 4096 bits of arch state

06:23 <sorear> every implementation of avx512 i'm aware of has either 1/cycle or 1/2cycle throughput; LMUL=8 will give you 1/8cycle or worse throughput on known implementations

06:23 <Sofia> Does a single RISC-V vector operation in its highest minimum setting, operate over more data than a single AVX512 operation?

06:23 <Sofia> Ah, so that 1/8 cycle or worse; you mean all the implementations essentially decompress the single operation into 8x sequential operations?

06:24 <sorear> if by "operation" you mean "single line of objdump output" then yes

06:24 <Sofia> instruction/opcode/4 bytes.

06:24 <sorear> I was going to say "atomic unit of forward progress wrt interrupts" but then I remembered vstart was a thing

06:24 <sorear> V wins more there because VEX encoding is kinda terrible

06:24 <Sofia> VEX?

06:26 <sorear> intel SDM, volume 2, §2.3.5

06:28 <sorear> (decompress) yes

08:56 <courmisch> sorear: FWIW, C908 peaks at LMUL=4 in most of my experiments, so I'm not sure it's as simplr

12:07 <another|> courmisch: do you have a c908?

12:36 <courmisch> err C910

12:37 <courmisch> nonmonotonic numbering sucks

16:13 <meowray> jrtc27[m]: are you going to write a proposal for an R_RISCV_RELAX relocation with a non-zero symbol index for non-RVC? (i think 0=>decided by EF_RISCV_RVC; non-zero=>no RVC)