[illumos-gate] 18328 Update AMD microcode to 20260724 -- Andy Fiddaman <illumos⊙fn>

hrm... iperf for some reason doesn't seem to cause tcp to generate many lso packets...

all morning, there's be exactly 1 so far ;P

lso packets?

large segment offload

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

and the NIC chops it up on it's own instead of requiring the OS to break it up into MTU-sized packets

isn't there a flag in iperf to say to use larger packets?

updating the IP and TCP header for each packet it generates

or would that not be large enough?

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)

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.

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

too late, I'm almost done with the send :)

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.

i've been enabling features one by one and trying to throw traffice at it for a while just as a basic smoke test

I just need to get some pressure off the existing zpool.

yesterday was TX and RX dma binding, then working on RX checksum offload today

(that diverted me into writing some mdb commands, which was in the plans anyway... just moved them up a bit)

thanks again for working on this. I really appreciate it.

the rx checksum is a bit annoying

basically the HW specifies a 'packet type' and there's a giant lookup table to figure out what offloads are present

(1024 entries, most are unused)

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

sounds like a serious bother

jbk: re lso, did you verify that LSO was negotiated all the way up?

just driver<->nic so far

given the wonderful history of Intel NICs w/ LSO, this is something i really want to test hard...

though i do think I finally understand what's actually happening (including the i40e)

enlightenment? in *this* economy?

it required a bit of archaeology

I can dig it.

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

(i'm guessing there's at least 1-2 people in here that will get that)

sounds like song lyrics but I can't place it.

it is

I'm pretty sure I'm familiar with the song but I just can't bring it up.

Sometimes I miss my mind the most.

I can even hear some of it in my head. arrggh

the piano bit (riff? basically playing around with an Am7 chord) was sampled for something a few years ago...

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

the ill is showing it at least.. still working further upstack

hrm... so the conn_t's ixa doesnt' seem to show it

maybe checksum is missing

doh!

it is (for TX)

i thought i had turned that on

(as in it is missing)

Hi, I'm trying to push my code review for 17965 to Gerrit but it's failing like this:

$ git push illumos HEAD:refs/for/master

** WARNING: connection is not using a post-quantum key exchange algorithm.

** This session may be vulnerable to "store now, decrypt later" attacks.

** The server may need to be upgraded. See openssh.com/pq.html

Enumerating objects: 89365, done.

Counting objects: 100% (89362/89362), done.

Delta compression using up to 4 threads

Compressing objects: 100% (25870/25870), done.

Writing objects: 100% (68657/68657), 110.39 MiB | 629.00 KiB/s, done.

Total 68657 (delta 51756), reused 54539 (delta 38084), pack-reused 0 (from 0)

remote: Resolving deltas: 100% (51756/51756)

error: remote unpack failed: error Missing tree 948f09956c00c13bfb34e60bf42d879f83684a52

fatal: Unpack error, check server log

To code.illumos.org:illumos-gate.git ! [remote rejected] HEAD -> refs/for/master (n/a (unpacker error))

error: failed to push some refs to 'code.illumos.org:illumos-gate.git'

switch to your main branch, fetch the illumos upstream, then rebase your branch

(at least that works for me when i've seen that)

there might be a simpler way

Ahh, yes, that made the trick, thanks!

np

anyone else seeing slow redmine responses?

rzezeski - yes, for a while now

[illumos-gate] 18315 want integrity checking for the devlink database -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 818 door_xcreate(3C) manual page needed -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 18316 getmntent() falls back to parsing mnttab as text after any ioctl error -- Andy Fiddaman <illumos⊙fn>

hrm.. we don't track anywhere (kstat?) how segmented an mblk_t is, do we?

You mean the number of b_cont chains?

yeah

doh!

I don't know of a kstat for that in mac (guessing that's what you're asking about)

yeah..