[illumos-gate] 18100 Linker should merge gcc_except_table sections -- Joshua Carp <jm.carp⊙gc>

jbk: is there a ticket I can watch for E380 support? I'm not seeing anything in illumos.org/projects/illumos-gate (but I could very easily be missing the obvious).

not sure if there's one filed yet

we tend to be bad about filing stuff early

because there's approximately 0 risk of conflicting work

though on a related note, is anyone keeping up with that realtek driver danmcd didn't like?

(I'm sorry, that's the only memorable detail of it for me)

I'm not sure if someone is fixing it, or not noticing Dan's actual feedback

E380?

Or E830 ?

E830. <sigh>

Though even with the correction I'm not finding any open tickets.

I'm guessing this means we're probably "more than a few months" from getting a working driver for this card.

i'm working on it, but it's a slog

intel made it so f$#@$@# complicated... for comparison, the freebsd _source_ for it's ice driver is several megabytes in size

y'all thought I was crazy when I complained about this trend 20 years ago :)

(I probably was, to be fair)

it's all of the non-NIC stuff, and the problem is even if you want nothing to do with it, you can't avoid it

jbk: so ice is the device name? At least I got that much right in labeling the host yesterday.

and the quality of intel's documentation has been steadily going downhill as well, so you end up having to reverse engineer the bits that are poorly explained in the documentation

This doesn't sound like fun.

it's certainly a grind..

but will be nice to have once it's done...

I appreciate your effort.

on a completely difference subject... i'm curious if anyone's given any thought to backpressure mechanisms in the I/O stack...

e.g. if you run non-local storage, zfs will throttle itself (possibly severly) because AFAICT there's no way for a device to really say 'i'm full, wait and try again'

jbk: guess there's the question of what ZFS can do when waiting for a device to not be "full".

and what "full" actually means. I can imagine some queue occupancy controls (no more than X outstanding write requests?)

just pause sending i/o

right now it does that after a few i/os

which often leaves a pretty fair amount of performance on the table

you can bump the r/w tunables globally

but i'm guessing the 'right' values for an HDD vs. SSD vs. array could all be different

and the existing standards seem to have various flavors of 'queue full' errors

(we even have a code for it with sd, but doesn't appear to be generated or really used)