I'm not looking to change the logic as much as just use the busra functions to store and manipulate all the resource data during all the various enumeration loops instead of pci_bus_res

since they seem to be doing the same thing, but the busra stuff uses dips, which means fewer places where things need to care about what segment they're in

I see, that clarifies the scope a bit. I've not looked at those APIs in great detail. Sounds like they could help. I think my big questions would ultimately remain around debugging and testing at the end of the day.

jbk: so I was looking at one place where packets can linger; the tcp reassembly queue -- and annoyingly it has no statistics for how many mblks and bytes are enqueued.

but it does look suspiciously like the reassembly queue is where packets are getting stuck.

might be worth adding the stats..

jclulow: so was part of the cubic issue related to recovery from loss events?

okay, yeah, it's the congestion control mucking things up.

CWND gets bigger than the window size, a packet gets dropped somewhere, and a full window ends up on hte transmit queue and in the reassembly queue on the receiver before the sender can ship a replacement for the missing segment

with sunreno, CWND stays below the window size.

linux mitigates this somewhat with the "tcp small queues" - there's a limit to how many packets can be in the tx queue. they kick off additional in-window transmits as packets are freed from the driver transmit queue.

jclulow: I'll open a bug on the CUBIC behavior - would appreciate it if you could add what you observed.

jbk: I was able to extract a reasonable proxy with dtrace (sequence-space span of the packets in the reassembly queue)

sommerfeld: Yeah there were definitely drops on the switch between speeds

illumos.org/issues/17907 escaped a little early -- I'm going to be filling out more detail in the description shortly.

okay, I'm done updating illumos.org/issues/17907

→ BUG 17907: tcp CUBIC overruns LAN receiver (New)

sommerfeld: freebsd/freebsd-src 038699a is potentially interesting (though there's been other updates, IIRC, this was all ported from freebsd to begin with, so the code shouldn't be too different (hopefully)

it also looks like a new rfc on cubic has been published since our implementation

(9438)

jbk: that seems likely to be relevant

i'd need to look at our implementation more closely, but this bit of rfc9438 seems potentially relevant:

Some implementations of CUBIC currently use _cwnd_ instead of _flight_size_ when calculating a new _ssthresh_. Implementations that use _cwnd_ MUST use other measures to prevent _cwnd_ from growing when the volume of bytes in flight is smaller than _cwnd_. This also effectively prevents _cwnd_ from growing beyond the receive window. Such measures are important for preventing a

CUBIC sender from using an arbitrarily high cwnd _value_ when calculating new values for _ssthresh_ and _cwnd_ when congestion is detected.

do we remap the address of the ACPI tables, or should the address from AcpiGetTable() (assuming success) from early boot, still be valid once the OS is up and running?

I don't know, sorry.

I would expect because of where it shows up in the memory map it doesn't get relocated.

that's what I suspect as well, just couldn't tell for sure.. though I suppose there's one way to find out :)

You can just look at the VA mapping later nad see if it maps to the same PA.

[illumos-gate] 17905 mdb: iob_doprnt() should know %j and %z -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 17870 page coloring interfaces should be in page.h -- Richard Lowe <richlowe⊙rn>

[illumos-gate] 17871 setx86isalist shouldn't be globally visible -- Richard Lowe <richlowe⊙rn>

[illumos-gate] 17872 many i86 parameters don't parameterize anything -- Richard Lowe <richlowe⊙rn>

The Solaris team at Oracle have published the PF firewall sources for Solaris 11: mastodon.illumos.cafe/@alanc⊙hi/116172554140885692

But not the kernel bits. :(

Oh I stand corrected.

yeah..

a long time ago I had wanted to play around with implementing this: usenix.org/conference/nsdi-08/swift-fast-dynamic-packet-filter on illumos.. though for filtering is maybe not as useful (since I suspect that aside from the initial connection, most of the 'filtering' would be more looking up a connection in some fashion to tell if the packet should proceed)

though maybe interesting as an alternative to pfmod (not to be confused with the above pf firewall)

pfmod(4M)

Guys, a question: I am running Tailscale (a mesh net) in a sparse zone on my OmniOS NAS. It uses tun to create a endpoint. I handle this endpoint s a untrusted network connection, firewalled on the outer perimeter of the zone (enforced firewall rules from GZ). Still, the tailscale daemon runs as root, which makes me anxious. Is there anything else I can do to reduce the bast radius?

You could forced priv the tailscale daemon, if you knew the privs it really needs

danmcd: is nahum around, this sounds like something he'd enjoy?

richlowe: : thx, will look into it.

or, you could figure out what privs it needs in normal operation iteratively using ppriv -D

start it with a limited set, wait for it to trip on something, add it to the set, restart, and repeat until you've exercised all the functionality you expect to need.

yeah, that's the way for forced priv. I figured nahum might do it "properly" natively (nahum's the person who does the illumos tailscare and wireguard ports)

so better placed to drop for eg file_dac_read

danmcd: the kernel bits covered by third party open source licenses, like the pf code from OpenBSD, are included, just not the more interesting kernel bits

Makes sense.

it's still a big head start for someone who wanted to do the work, it's just not foolproof

as much as our build systems are ever foolproof

and there is more than you'd expect under directories like osnet/usr/src/uts/common/vm/ that still have ancient BSD heritage

but under osnet/usr/src/uts/common/fs/ you'll find ufs, not zfs

alanc: I'd want to be further understanding ours before even thinking of understanding yours

but our VM has such fun terms of art such as bread line, credits, wallets, and the fed reserve

though that's in the files we didn't release, since they didn't come from a BSD

so no source code for fed_redistribute_reserve() or fed_breadline_soupline_demand()