[illumos-gate] 18434 Want man page for userattr(1) -- Andy Fiddaman <illumos⊙fn>

omg... RSS is _finally_ working!

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)

I know there's active work on it, though I don't know what is or is not working

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

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?

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

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

jbk: MAC already does fanout which is why we usually do more rings than interrupts.

So I don't think you need to do anything fancy there and can just rely on the existing mac srs and further softrings.

even with RX?

Yes.

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.

Those are all separate from the hardware ring polling thread.

Also the "USE OF WORKER THREADS" section has some prose there.

But also, having more hardware queues than interrupts is fine.

You ultimately want a ring to enter polling thread which will be done on a dedicated CPU.

And if doesn't enter polling mode, then it probably doesn't matter.

good point... it probably means the inbound rate is low enough to not care...

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.

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. ;)

No reason to make it even harder.

heh.. this nic is hard enough :)

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)

(reality might be different of course)

nomad: if you still want to test, it's I think (finally) ready

hrm weird... in a non-debug build smatch is complaining about a failed CTASSERT that gcc does not (the CTASSERT is correct)

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

jbk: What specifically do you mean by OCP support?

jbk: I am interested in testing, yep, youbetcha.

(by 'it' I presume you mean the ICE driver.)

that host is currently running OmniOS 151045bs.

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')

nomad: ok.. are you familiar with building illumos? if not i might need to think how I can get you the driver...

I am not.

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).

ugh, typo. It's running 151054bs

current LTS.

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)

that you could then install

the test system i've been using is on 151058s

I bet andyf has advice on this topic :)

so it'd _probably_ be ok, but why not be safe

(danmcd too, but he doesn't seem to be in channel right now.)

oh .p5m i was close

err no that's the manifest extension

you were right about p5p

At least it's not pascal

jbk: the example you want is in pkgrecv(1)

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.

i'll be traveling on Monday, but I'll see what I can do to get something setup...

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.

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.)

It's ready when it's ready. What's one more week? :)

jbk: What section of the ice docs?

rm: 12.10 (it mentions both SMBus I think for the BMC but also PCI access)

(I have rev 2.7 if that's relevant)

hrm.. it looks like some of the stuff under usr/src/cmd/boot is grabbing headers from the build env

(not sure if direct or indirectly)

(specifically it bombed on bblk_einfo.o)

i'm attempting to build the r151054 illumos-omnios branch w/ the driver code cherry-picked but on slightly newer omnios