richlowe: anything specific?

we build our fork w/ libressl

but i'm not sure offhand what was involved (e.g. just ignore/nuke bits we don't use that delve into openssl internals)

though we also do have a number of patches applied as well

well they exist.. i'm not sure looking at them that they'd be relevant at all

pmooney: one of my 2 nodes is broadwel

E5-2680 v4

hi all, i see we have removed 'bus_mps' from pcie_impl.h and some code, but i see comments with it at many places . will be better to remove all references about 'bus_mps'

Sounds good, no objection here.

For those following along outside the joined/left spam... Here's t he Broadwell MSR info for pmooney

0x48c: 0xf0106334141

(Same as my Haswell sample(s).

is there any go lib for listening to illumos system events?

i don't think so

but be careful

./just-got-very-scared

I saw github.com/tritondatacenter/node-sysevent

Was hoping to create a counter for when physical interfaces change their link state

IIRC the sysevent client library starts a door server to recieve events

not sure if that's already available in kstat

and if you fork() at the wrong time

you hit a deadlock, and your process is unkillable

(it's a really thorny problem, so it's easier to work around it)

ahhh ok, will go a different way lol

if you fork a helper before attaching to sysevents, that works around it

This is interesting, makes me want to setup a lab to test the optimization case with illumos youtu.be/36qZYL5RlgY

jbk if you have time, could you check over code.illumos.org/c/illumos-gate/+/2437? :)

→ CODE REVIEW 2437: 15067 linker set should be declared WEAK (NEW) | illumos.org/issues/15067

thanks!

tsoome_: thanks for updating the tests on that linker-set work

it'll be nice to have that covered into the future

thanks for pointing to them, it is easy to forget about...

I've been trying to make it a habit of adding tests for new stuff

even if they are short or have incomplete coverage

something is better than nothing

tests which are using test-runner also benefit from tagging now, I have found it extremely useful with zfs tests

Smithx10: You could just configured syseventd tbh

see also syseventadm(8)

jclulow: ahhh ok

I believe you can just run any program in response to a particular sysevent

I'm really just interested in knowing how many times a physical link state changes

Think sysevent is the right facility for that?

I know that dmesg will log it, and maybe it would be better to just grok that ?

that would probably be better

So, I would poll a kstat first

if there is one

And if there is not, that seems like a good RFE

but syseventadm seems very reasonable otherwise

It's pretty much what it's there for

so you can do a thing in response to a system thing

[illumos-gate] 14957 pcieadm overloads header1.iobasehi -- Robert Mustacchi <rm⊙fo>

`kstat -p ::mac:link_up`

if someone sends us an ICMP destination uncreachable message, do we actually do anything (e.g. route black hole)?

We percolate ENETUNREACH up to appropriate sockets if the inner packet has enough for us to match upon.

We may also rate-limit those because face it, some jackass could just spam you with 'em.

but that wouldn't impact _new_ sockets to the same IP, right?

Once traffic moves, and subject to the aforementioned rate-limiting.

(You'll have to get a fresh ICMP_DST_UNREACH for those new sockets.)

rzezeski: Thanks, but polling that every 15 seconds really doesn't help with measuring if its flapping

Think I might just inspect the kernel log for messages from within the prometheus scrape interval and bump the counts

If you're going to scrape at least scrape the ireport log so you can see the structured info.

rmustacc: ireport log ? not sure what that is

i suppose you could rig something up with dtrace as well -- just whenever mac_link_update() (or whatever it's called.. don't have it in front of me) is called..

I mean, we could also add a kstat to count up/down events

that too :)

rzezeski: that would be the <3

and honestly, that seems like a reasonable thing to add as kstats are useful for knowing that some type of behavior has been happening without the need to log/dtrace the entire time

like "oh wow my link has flapped 7777 times since boot, that seems wrong"

we hacked together something, to find it happening throughout our fleet, but wanted to get it into grafana, currently we just use the cmon plugins (github.com/TritonDataCenter/triton-…cmon-agent/tree/master/docs#plugins). The Grok makes more sense for the scrape interval because I dont want to add another daemon... But a kstat would make this simpler

network folk / dc team gets a nice email now

Smithx10: okay well unless rmustacc knows of something that exists for this or has some objection I think it's worth adding an illumos issue, should be easy enough for any of us to pick up (lol anytime I say something is easy it turns out cursed)

seeing the following when building bhyve-tests: pastebin.com/FqzZiXw7, is it just me?

hmm, pushed on Oct 2, must be something local; could it be related to binutils being 2.25?

sounds possible