10:49:11 [illumos-gate] 18328 Update AMD microcode to 20260724 -- Andy Fiddaman 16:49:35 hrm... iperf for some reason doesn't seem to cause tcp to generate many lso packets... 16:49:52 all morning, there's be exactly 1 so far ;P 16:53:54 lso packets? 16:54:11 large segment offload 16:54:37 for tcp, basically the os can pass down a 'big packet' (not really sure if there's a term for it) up to 64KiB in size 16:54:55 and the NIC chops it up on it's own instead of requiring the OS to break it up into MTU-sized packets 16:55:10 isn't there a flag in iperf to say to use larger packets? 16:55:12 updating the IP and TCP header for each packet it generates 16:55:45 or would that not be large enough? 16:56:39 according to the man page, it's already writing 128KiB chunks of data (tcp is of course free to break up and reassemble things as it wants for the most part) 16:56:48 I'm currently zfs send | receiving a couple 4TB filesets from $oldfileserver to the not-yet-in-production $newserver. I was idly wondering if that would be a good test for the driver. 16:57:28 i mean.. if you want to try out what's there, you can... just I can't promise it won't stall or panic the system 16:57:45 too late, I'm almost done with the send :) 16:58:29 I'm hoping by doing this i can reduce the pressure to move stuff to the new server. I'm moving datasets that - in theory - are not in active use so no one *should* care if I bounce the server later, doing actual tests. 16:58:30 i've been enabling features one by one and trying to throw traffice at it for a while just as a basic smoke test 16:58:37 I just need to get some pressure off the existing zpool. 16:59:13 yesterday was TX and RX dma binding, then working on RX checksum offload today 16:59:28 (that diverted me into writing some mdb commands, which was in the plans anyway... just moved them up a bit) 16:59:29 thanks again for working on this. I really appreciate it. 17:00:06 the rx checksum is a bit annoying 17:00:47 basically the HW specifies a 'packet type' and there's a giant lookup table to figure out what offloads are present 17:03:12 (1024 entries, most are unused) 17:06:24 if i was more ambitious (I'm not :P) we could write a custom classification program that runs on the NIC and just tells us the stuff we care about 17:20:46 sounds like a serious bother 17:22:12 jbk: re lso, did you verify that LSO was negotiated all the way up? 17:23:57 just driver<->nic so far 17:52:22 given the wonderful history of Intel NICs w/ LSO, this is something i really want to test hard... 17:52:47 though i do think I finally understand what's actually happening (including the i40e) 17:57:47 enlightenment? in *this* economy? 18:01:13 it required a bit of archaeology 18:03:17 I can dig it. 18:08:25 well I have been waiting for such a long time (to figure it out)... and the 4th of july was on a saturday this year, so... :P 18:08:57 (i'm guessing there's at least 1-2 people in here that will get that) 18:09:12 sounds like song lyrics but I can't place it. 18:09:34 it is 18:11:43 I'm pretty sure I'm familiar with the song but I just can't bring it up. 18:11:50 Sometimes I miss my mind the most. 18:12:12 I can even hear some of it in my head. arrggh 18:12:32 * nomad cranks up the Mannheim Steamroller to drown it out 18:13:29 the piano bit (riff? basically playing around with an Am7 chord) was sampled for something a few years ago... 18:15:13 jbk: if you aren't seeing LSO packets at the NIC/mac_tx, then I would verify that LSO has been negotiated at TCP/IP 18:27:21 the ill is showing it at least.. still working further upstack 18:34:23 hrm... so the conn_t's ixa doesnt' seem to show it 18:34:45 maybe checksum is missing 18:37:04 doh! 18:37:28 it is (for TX) 18:37:32 i thought i had turned that on 18:38:50 (as in it is missing) 19:17:00 Hi, I'm trying to push my code review for 17965 to Gerrit but it's failing like this: 19:17:07 $ git push illumos HEAD:refs/for/master 19:17:07 ** WARNING: connection is not using a post-quantum key exchange algorithm. 19:17:07 ** This session may be vulnerable to "store now, decrypt later" attacks. 19:17:07 ** The server may need to be upgraded. See https://openssh.com/pq.html 19:17:07 Enumerating objects: 89365, done. 19:17:09 Counting objects: 100% (89362/89362), done. 19:17:12 Delta compression using up to 4 threads 19:17:14 Compressing objects: 100% (25870/25870), done. 19:17:17 Writing objects: 100% (68657/68657), 110.39 MiB | 629.00 KiB/s, done. 19:17:20 Total 68657 (delta 51756), reused 54539 (delta 38084), pack-reused 0 (from 0) 19:17:22 remote: Resolving deltas: 100% (51756/51756) 19:17:25 error: remote unpack failed: error Missing tree 948f09956c00c13bfb34e60bf42d879f83684a52 19:17:28 fatal: Unpack error, check server log 19:17:30 To code.illumos.org:illumos-gate.git ! [remote rejected] HEAD -> refs/for/master (n/a (unpacker error)) 19:17:33 error: failed to push some refs to 'code.illumos.org:illumos-gate.git' 19:17:49 switch to your main branch, fetch the illumos upstream, then rebase your branch 19:18:03 (at least that works for me when i've seen that) 19:18:06 there might be a simpler way 19:20:14 Ahh, yes, that made the trick, thanks! 19:20:38 np 19:55:20 anyone else seeing slow redmine responses? 20:24:29 rzezeski - yes, for a while now 20:37:16 [illumos-gate] 18315 want integrity checking for the devlink database -- Andy Fiddaman 20:37:16 [illumos-gate] 818 door_xcreate(3C) manual page needed -- Andy Fiddaman 20:37:16 [illumos-gate] 18316 getmntent() falls back to parsing mnttab as text after any ioctl error -- Andy Fiddaman 22:49:30 hrm.. we don't track anywhere (kstat?) how segmented an mblk_t is, do we? 22:51:28 You mean the number of b_cont chains? 22:51:55 yeah 23:46:34 doh! 23:49:20 I don't know of a kstat for that in mac (guessing that's what you're asking about) 23:49:37 yeah..