[illumos-gate] 17710 SMB: want unified mac functions -- Matt Barden <mbarden⊙rc>

[illumos-gate] 17711 SMB: use single-shot scatter/gather interfaces for signing -- Matt Barden <mbarden⊙rc>

[illumos-gate] 17712 smb: support signing capabilities negotiation context -- Matt Barden <mbarden⊙rc>

[illumos-gate] 17713 SMB 3.1.1 should support GMAC signing -- Matt Barden <mbarden⊙rc>

is the BCM57504 (Netextreme-E 10GB-100GB NIC) something that would likely be supported by an existing driver (with maybe a few tweaks) or is it one that needs a whole new driver? I thought there were BCMs nics that fell into both categories, but since they seem to produce a zillon different variants, I've not been able to really keep straight what's what

I thought that one is essentially the missing bnxt(4D) driver.

s/missing/WIP/g

ahh ok

i do need to upstream this USB fix (or i guess workaround) for some virtual USB from various BMCs (so far seen it with Intel and now this Dell AMD system)

bge was the old-school Broadcom NetXtreme-I (their moral equivalent of Intel's e1000/igb).

(I've seen bge parts on modern-ish mobos)

bnx was GigE NetXtreme-II (?) bnxe was 10GigE .

Yeah, I can see why one would get confused.

especially if you only deal with it one every few years

Besides the MIB counters that are standardized, is there any reason not to increase the width of non-standard counters in mib2_tcp_t? For example, I want to fix 17790 (tcpInAckSegs is always zero), but notice that it's 32-bit along with several other counters which would have a high change of rolling over like InData*Segs counters.

1.) I don't see a reason not to widen those counters across the board as long as the MIB standard ones get clipped if need be.

The tricky part about the MIB is that our netstat (as your recent bug update tells me you know about) uses the MIB.

I don't think that's a public interface - at least I did not find anything in the man pages.

2.) Apart from my bigger-picture things in 1, I think we'll be okay widening what you want. I'm SUPER curious what it'll end up looking like.

Oh. Out-of-gate things like net-snmp use them.

andyf: can you point me to that?

Yes, and MAYBE routing daemons too (e.g. quaaga ?)

danmcd: yea mainly I want to widen the counters tracking segs/bytes, because in today's world those will easily roll over

Also if/when we start fenix fenix` ipd 14 we'll want to take that opportunity to widen anything else we need to in userland that isn't a public interface.

IPD 14: illumos and Y2038 (predraft)

↳ github.com/illumos/ipd/tree/master/ipd/0014/README.md

but github has a few different projects that use those types

(once you filter through all of the illumos forks!)

well damn

maybe I could leave mib alone and feed netstat another way for these counters, haven't looked at the code long enough to see how it's all structured

Who doesn't love snmp-over-/dev/arp?

gotta love some legacy

ALso: datatracker.ietf.org/doc/html/rfc4293

you could put full-width counters in new members

We might wann push to that.

old consumers will read short, get the short ones

new consumers will read long, and get BigThingyExit

uh, what, BigThingyExt

andyf: do you have good github search magic to remove the illumos?

I just scroll and scroll and scroll, but if it can be automated...

danmcd: is there anything in particular you are pointing me to with RFC 4293?

The existence of "HC counters" mostly. My SNMP-fu is very weak, however.

richlowe: are you saying replicate those members onto the end of mib2_tcp_t?

I remember during my IETF days that it was a busy-maybe-contentuous place but I was busy with other things.

Okay yea I was looking at RFC 4022 earlier along with the earlier MIB RFCs to see if they define any of the ones I want to change, but pretty sure these are all non-standard counters we added

rzezeski: yeah, just an idea, and one I'd want someone else to check my thinking of

it depends on the interface to get hold of one

if they can be got into fixed buffers, that doesn't work

richlowe: k, yea just wanted to make sure I followed what you were saying

if it's only member placement and size that matter, you can sometimes cheat

richlowe - no magic, just scrolling.

My initial feeling is I hate to keep putting things in a structure prefixed "mib2" when it is absolutely not defined in the MIB standards (or whatever these things are called). So if I can just place this stuff somewhere else so kstat and netstat can report accurate results, and not effect any changes to the mib stuff, I feel like that might be best. But I need to dig more.

I would definitely not be against that, but I'm not a networking person

sommerfeld and danmcd are probably the people I'd check with

The mib2 thing goes back to the earliest days of Mentat Portable Streams. IIRC the mib data is delivered via ioctl to its consumers

This header: #include <inet/mib2.h> is most likely one of your initial reference points.

who among you has the most physical memory? I think 2T or more would be a good ballpark? I would be grateful if you showed me `mdb -ke 'valloc_sz/E'`

Funny thing about mib2.h, we in SMartOS have a our-distro-only putback-buddy from 2020.

illumos-joyent: e0823b796aeea75fe40ec8888eb84ca5a25cff39

Oh wait... we modify it other ways too... it is on us.

"[fix build - missing local modifications]"

danmcd: seems like he copy/pasted a comment that isn't right, too

(i just did `git show`, but they can't both be current rto, right?)

Looking now to see its history.

OS-7944 from SmartOS.

fenix OS-7944 (work?)

: ()

↳ smartos.org/bugview/OS-7944

hadfl: seems fenix is having trouble with smartos synopses

and/or is making faces

Heh... we should probably upstream this.

Ulyssa was doing good work back then on things networking.

richlowe: I'm less interested in the summary (we did change how we render smartos.org/bugview recently, I don't see Nahum on here anymore but he can better explain), and more interested in Just The Link (TM). :)

danmcd: as long Nahum keeps tailscale alive and kicking, anytihng else can be overlooked :)

So I have a OS-7944 branch now on danmcd/illumos-gate.

(Fixed the comment too.)

richlowe: 2T is now what, maybe $32,000 worth of memory? (I'm seeing quotes for 64GB at just under $1K)

sommerfeld: yeah, the prices went through the sky. I think it was reasonable (not for a personal machine, but for the corps. here) a year or so ago

That tracks. :( I'm opting for HDC 3.5: The Recasing this year instead of a full blown HDC 4.

I was talking to jbk about how spinning rust was on the verge of doing it, I think that happened happened too

so now you can't store bits anyplace

I don't know what HDD prices were last year, but compared to what I ponied up for my 14TB disks the price-per-TB is on par.

(I hope to pick up before they disappear a set of 22TB drives.)

saw a headline saying that someone from Western Digital said they were sold out for 2026 already

Me too... I can only pray to the gods of warehouse availabiity.

(And cash flow... )

Is there a way to find out the zoneid a link belongs to? I have dladm_handle_t dh, datalink_id_t linkid. On Solaris it is easy with dladm_datalink_id2linkinfo().

jelmd: I'm not an expert, but I'm not immediately seeing anything

:(

thanx for checking :)

jelmd: Try the zone linkprop maybe?

If there's value it'll give you the zone name.

*there's a value

jelmd: from the command line, "dladm show-linkprop -p zone $linkname"