Is there a modern eth vendor that is friendly with Illumos and providing any support these days?

Based on what I see on the mailing lists, Intel isn't being very helpful, and in general are not considered all that good for ethernet. Mellanox get high praise, but no support from Nvidia, and Illumos' driver is basically the bare min feature set to push packets in and out with no offloads.

Broadcom's 25Gb kit isn't supported in Illumos.

(Some of the more current Intel stuff isn't supported either IIRC)

There's Solarflare, no experience with their kit.

I think Chelsio is the only other option, again no experience with them either.

Kurlon: Chelsio is pretty good (Oxide has 'em lined up). Mellanox can be improved with motivation... a customer of ours is a big Mellanox shop and has helped us deal with Mellanox in the past. Also arekinath (who isn't here now?) has done work in the past on mlxcx and may have staged changes in his repos.

tsoome_: i know you've talked about it in the past, but have you done anything yet to allow access to efi vars from a booted kernel?

jbk thats not done yet.

danmcd: Reading some of the papers Chelsio has bragging about their perf on Illumos is encouraging. Mellanox is easy to source though, and seeing as I've already got one adapter, if I can help improve their perf I'm game.

Plan is to swap my problem box to an Intel X520 for now, that will let me pull the CX5 into my 'lab' for more aggressive testing.

Kurlon_: biggest immediate win I can think of is TSO (aka LSO). I think arekinath (still not here) may have a larval/prototype version of THAT.

Check his illumos-joyent on github.

and if you're doing chelsio + virt, make sure you pull pmooney's fixes from Dan's investigations.

has anyone used libzdoor? is it possible to execute a process from a NGZ to a GZ using that ? (security concerns aside)

I haven't, but you can share a door yes, and your door server could respond to requests that way?

everything in the system (I hope) does it the other way, and has a GZ daemon that injects a door into the zone for a client

richlowe thanks, I'll read more about doors then seems I kind of lost

I think what you'd end up needing is a daemon in the GZ that arranges itself like I think zonestatd does, and then listens on its door and execs whatever your thing is when requested.

I was trying to have some api to provision zones, and want to check the status of the zones from that ngz, seems I just create a rest endpoint in gz to query zones

I'm not sure what triton does, but I imagine they and the oxide stack (I imagine it's in omicron, everything is in omicron) are the models to follow :)

I wrote a Rust crate that makes it pretty easy to be a doors server, FWIW: github.com/oxidecomputer/doorjamb

You can also poke a UNIX domain socket into a zone, if that floats your boat.

That's how bits of the SmartOS metadata stuff work

The crates.io/crates/ucred crate should enable you to tell who is on the other side of a connection (or a door call)

if doorjamb abstracts over the annoying bits, that is especially good

unfortunately, there still isn't a good way to do 'cleanup' after door_return().. ISTR someone at Sun said they were going to work on it, but guess that never happened

(i think everyone either just puts it all on the stack and lets the unwinding do it, or lets it more or less leak at least a bit)

i had wondered what it'd take to do that, but it seems tricky

danmcd: I couldn't find a recent repo for arekinath, his joyent is about 10yrs old, no mlxcx driver at all. I did find a Joyent pull request that looks potentially viable for investigation though: TritonDataCenter/illumos-joyent #223

Bah, wrong pull.

444, not 223

Looks like LSO and some other tune ups if I'm reading things correctly.

jclulow thanks, I'll take a look at the crate

Oh yes... I created that branch as a holding cell. Forgot about that.