03:00:34 [illumos-gate] 17710 SMB: want unified mac functions -- Matt Barden 03:00:34 [illumos-gate] 17711 SMB: use single-shot scatter/gather interfaces for signing -- Matt Barden 03:00:34 [illumos-gate] 17712 smb: support signing capabilities negotiation context -- Matt Barden 03:00:34 [illumos-gate] 17713 SMB 3.1.1 should support GMAC signing -- Matt Barden 15:48:40 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 15:59:59 I thought that one is essentially the missing bnxt(4D) driver. 16:00:42 s/missing/WIP/g 16:12:35 ahh ok 16:13:41 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) 16:14:57 bge was the old-school Broadcom NetXtreme-I (their moral equivalent of Intel's e1000/igb). 16:15:08 (I've seen bge parts on modern-ish mobos) 16:16:22 bnx was GigE NetXtreme-II (?) bnxe was 10GigE . 16:16:28 Yeah, I can see why one would get confused. 16:24:04 especially if you only deal with it one every few years 19:50:22 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. 19:54:38 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. 19:54:57 The tricky part about the MIB is that our netstat (as your recent bug update tells me you know about) uses the MIB. 19:55:07 I don't think that's a public interface - at least I did not find anything in the man pages. 19:55:36 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. 19:56:47 Oh. Out-of-gate things like net-snmp use them. 19:57:31 andyf: can you point me to that? 19:57:56 Yes, and MAYBE routing daemons too (e.g. quaaga ?) 19:57:59 danmcd: yea mainly I want to widen the counters tracking segs/bytes, because in today's world those will easily roll over 19:58:27 https://github.com/net-snmp/net-snmp/blob/master/agent/mibgroup/kernel_sunos5.c#L88 19:58:31 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. 19:58:31 IPD 14: illumos and Y2038 (predraft) 19:58:32 ↳ https://github.com/illumos/ipd/tree/master/ipd/0014/README.md 19:58:35 but github has a few different projects that use those types 19:58:43 (once you filter through all of the illumos forks!) 19:59:07 well damn 19:59:47 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 20:00:02 Who doesn't love snmp-over-/dev/arp? 20:00:24 gotta love some legacy 20:00:32 ALso: https://datatracker.ietf.org/doc/html/rfc4293 20:00:41 you could put full-width counters in new members 20:00:43 We might wann push to that. 20:00:48 old consumers will read short, get the short ones 20:00:54 new consumers will read long, and get BigThingyExit 20:01:00 uh, what, BigThingyExt 20:01:51 andyf: do you have good github search magic to remove the illumos? 20:02:00 I just scroll and scroll and scroll, but if it can be automated... 20:02:52 danmcd: is there anything in particular you are pointing me to with RFC 4293? 20:03:51 The existence of "HC counters" mostly. My SNMP-fu is very weak, however. 20:03:52 richlowe: are you saying replicate those members onto the end of mib2_tcp_t? 20:04:12 I remember during my IETF days that it was a busy-maybe-contentuous place but I was busy with other things. 20:04:50 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 20:08:12 rzezeski: yeah, just an idea, and one I'd want someone else to check my thinking of 20:08:48 it depends on the interface to get hold of one 20:08:59 if they can be got into fixed buffers, that doesn't work 20:09:00 richlowe: k, yea just wanted to make sure I followed what you were saying 20:09:09 if it's only member placement and size that matter, you can sometimes cheat 20:09:52 richlowe - no magic, just scrolling. 20:10:48 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. 20:16:10 I would definitely not be against that, but I'm not a networking person 20:16:30 sommerfeld and danmcd are probably the people I'd check with 20:24:56 The mib2 thing goes back to the earliest days of Mentat Portable Streams. IIRC the mib data is delivered via ioctl to its consumers 20:25:20 This header: #include is most likely one of your initial reference points. 20:26:33 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'` 20:27:31 Funny thing about mib2.h, we in SMartOS have a our-distro-only putback-buddy from 2020. 20:27:41 illumos-joyent: e0823b796aeea75fe40ec8888eb84ca5a25cff39 20:28:03 Oh wait... we modify it other ways too... it is on us. 20:28:05 "[fix build - missing local modifications]" 20:28:55 danmcd: seems like he copy/pasted a comment that isn't right, too 20:29:06 (i just did `git show`, but they can't both be current rto, right?) 20:29:08 Looking now to see its history. 20:29:33 OS-7944 from SmartOS. 20:29:44 fenix OS-7944 (work?) 20:29:45 : () 20:29:45 ↳ https://smartos.org/bugview/OS-7944 20:30:09 hadfl: seems fenix is having trouble with smartos synopses 20:30:19 and/or is making faces 20:30:49 Heh... we should probably upstream this. 20:31:15 Ulyssa was doing good work back then on things networking. 20:44:25 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). :) 20:47:59 danmcd: as long Nahum keeps tailscale alive and kicking, anytihng else can be overlooked :) 21:07:24 So I have a OS-7944 branch now on danmcd/illumos-gate. 21:07:51 (Fixed the comment too.) 21:10:20 richlowe: 2T is now what, maybe $32,000 worth of memory? (I'm seeing quotes for 64GB at just under $1K) 21:11:08 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 21:11:24 That tracks. :( I'm opting for HDC 3.5: The Recasing this year instead of a full blown HDC 4. 21:11:43 I was talking to jbk about how spinning rust was on the verge of doing it, I think that happened happened too 21:11:49 so now you can't store bits anyplace 21:12:26 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. 21:12:41 (I hope to pick up before they disappear a set of 22TB drives.) 21:13:24 saw a headline saying that someone from Western Digital said they were sold out for 2026 already 21:13:43 Me too... I can only pray to the gods of warehouse availabiity. 21:14:59 (And cash flow... ) 22:02:21 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(). 22:04:59 jelmd: I'm not an expert, but I'm not immediately seeing anything 22:05:09 :( 22:05:21 thanx for checking :) 23:37:47 jelmd: Try the zone linkprop maybe? 23:38:34 If there's value it'll give you the zone name. 23:38:42 *there's a value 23:52:02 jelmd: from the command line, "dladm show-linkprop -p zone $linkname"