09:50:50 [illumos-gate] 18434 Want man page for userattr(1) -- Andy Fiddaman 14:47:43 omg... RSS is _finally_ working! 14:49:26 Been wondering a bit, what's the current status of the aarch64 port? (Got an honeycomb LK2K, and an rpi3 with uefi setup, but no rpi4) 14:56:46 I know there's active work on it, though I don't know what is or is not working 15:01:06 though one open question is, at least on this system (though I don't think it's unique), we only get 8 MSI-X vectors for the PF while the each PF can support many more rings (easily # of cores in most cases)... for TX I don't think it'd be too much of a problem to share vectors since it's just for cleanup after TX, so you get all your parallelism 15:02:57 but on RX, I wondering if there's an existing strategy to be able to spread out the bulk of the RX processing across more CPUs (e.g. could the MSI-X shared amongst multiple RX queues just trigger a softint for each queue w/ data, and would that allow the system to spread the work out more? 15:19:56 No idea from me there at least, I usually touch the userland (libc included), very few times the bootloader, and kernel is just reading it when documentation is lacking 15:26:48 lanodan: you need at least an rpi4 the other two machines would be a bringup you would need to do and the pi3 needs to be one that supports 64bit. UEFI is not yet supported the boot still uses a custom uboot loader 15:27:19 jbk: MAC already does fanout which is why we usually do more rings than interrupts. 15:27:47 So I don't think you need to do anything fancy there and can just rely on the existing mac srs and further softrings. 15:32:58 even with RX? 15:33:14 Yes. 15:34:13 Look at the mac_sched.c receive data path image. Each soft ring has its own worker thread. So as you hit mac_rx_srs_fanout or mac_rx_srs_proto_fanout you already get spread. 15:35:27 Those are all separate from the hardware ring polling thread. 15:35:57 Also the "USE OF WORKER THREADS" section has some prose there. 15:38:05 But also, having more hardware queues than interrupts is fine. 15:38:16 You ultimately want a ring to enter polling thread which will be done on a dedicated CPU. 15:38:35 And if doesn't enter polling mode, then it probably doesn't matter. 15:39:08 good point... it probably means the inbound rate is low enough to not care... 15:39:30 Right and when it is high enough, each *ring* not, MSI-X is on a dedicated poller and even then it'll get fanned out even more when you get to the SRS. 15:40:19 So I probably wouldn't do experiments on redesigns here until after we get an initial form of the driver reviewed and integrated. Given all the regular complaints about it. ;) 15:40:29 No reason to make it even harder. 16:40:44 heh.. this nic is hard enough :) 18:15:19 tangentially related (just curious really) has anyone looked at adding OCP support for NICs in the kernel? it _looks_ like that could provide a standard way to report various useful things (FW versions, temperature, SFP power, etc) 18:15:36 (reality might be different of course) 18:39:14 nomad: if you still want to test, it's I think (finally) ready 19:44:55 hrm weird... in a non-debug build smatch is complaining about a failed CTASSERT that gcc does not (the CTASSERT is correct) 20:31:21 lanodan: rpi3 would require work, I'm not sure if it's worth it. rpi4 should be fine. if you need uefi/acpi Michael van der Westhuizen has a full set of changes we're slowly merging into the arm64-gate for that. I have seen it work on ampere (I think it was altra?) and grace. if you need rpi5 we have to sit down and support the custom I/O chip 20:59:40 jbk: What specifically do you mean by OCP support? 21:06:01 jbk: I am interested in testing, yep, youbetcha. 21:06:37 (by 'it' I presume you mean the ICE driver.) 21:07:40 that host is currently running OmniOS 151045bs. 21:13:35 rmustacc: for at least enumerating or managing some of the bits it exposes (at least how it's described in the ice docs)... it sounds like it'd give a common protocol for temp probes, leds, hw info, etc. (though i've not looked too deeply, just 'oh that looks like it could be neat') 21:14:13 nomad: ok.. are you familiar with building illumos? if not i might need to think how I can get you the driver... 21:14:32 I am not. 21:15:05 I have installed T-patches but that was long ago so I'd need a documentation pointer to remind me of the process (unless it's a simple pkg command). 21:16:48 ugh, typo. It's running 151054bs 21:16:51 current LTS. 21:18:06 I don't think I've ever done it, but I think (at least in theory) if I can get a build system w/ the illumos-gate build that's using, I could probably create a .p5p (I think that's the format for standalone pkg packages) 21:18:17 that you could then install 21:18:52 the test system i've been using is on 151058s 21:19:13 I bet andyf has advice on this topic :) 21:19:39 so it'd _probably_ be ok, but why not be safe 21:20:09 (danmcd too, but he doesn't seem to be in channel right now.) 21:25:13 oh .p5m i was close 21:25:24 err no that's the manifest extension 21:26:16 you were right about p5p 21:27:13 At least it's not pascal 21:27:36 jbk: the example you want is in pkgrecv(1) 21:28:04 I need to wander off for a while. I'll be back in a bit. I think I can start testing on Monday or Tuesday if it's ready. 21:28:36 i'll be traveling on Monday, but I'll see what I can do to get something setup... 21:29:01 fair warning, I have *nothing* fast enough to really test this. At best i can iperf3 against a bonded pair of 10GB. I'll just be pushing data through and checking for corruption. 21:30:02 We'll hopefully get a second host with this same card in early 2027, so I will probably be able to sneak in a speed test or two then (but we're configuring it as two 50GB NICs, not 100G ones.) 21:30:43 It's ready when it's ready. What's one more week? :) 21:38:22 jbk: What section of the ice docs? 21:39:14 rm: 12.10 (it mentions both SMBus I think for the BMC but also PCI access) 21:39:30 (I have rev 2.7 if that's relevant) 21:59:39 hrm.. it looks like some of the stuff under usr/src/cmd/boot is grabbing headers from the build env 21:59:45 (not sure if direct or indirectly) 22:01:58 (specifically it bombed on bblk_einfo.o) 22:03:19 i'm attempting to build the r151054 illumos-omnios branch w/ the driver code cherry-picked but on slightly newer omnios