The reality is that most folks are coming to ask for features from these because some app wants it, so that's always the lens to remember. I don't think anyone is going to be trying to pass a conformance test.

Hi to all, I'm moving my first steps with IlumOS distributions, and I'm banging my head around to find how to import a root CA certificate into OmniOS CA bundle... anyone here can kindly point me to the right direction? :)

warden: I could tell you how to do it on OpenIndiana since I wrote the responsible script ;)

you could check for a SMF service called ca-certificates (svcs ca-certificates) and it it exists, put you new root ca in PEM format into /etc/certs/CA and run svcadm refresh ca-certificates

Agnar: thanks, I already searched for it, but no service like this seems to exist in OmniOS :(

they should adopt it ;)

sorry...

have you checked their website?

You are right!:) I guess the bundled CA list in OmniOS is under /etc/ssl , but I didn't find any documentation about that

or just find /etc -name \*.pem

and the bundle of course, ca-certificates.crt

putting my CA pem file into /etc/ssl/certs didn't seem to work

well, I'll go on with a trial-and-error process... :)

your tools might read the bundle file, so you need to append it there also

actually my wish is to make integrated wget and curl binaries to work without the "-k" workaround

Agnar: I'll go on trying to mangle further into /etc/ssl contents. Thanks for your suggestion.

warden what version of OmniOS are you running? I can help once I am back at a proper keyboard but I am surprised you need to use "-k" if it's a public web server. Perhaps omnios is missing some certificate updates and we should get that fixed.

andyf: thank, but the bundled CA list is ok as for me, I'm only trying to add my private root CA into it

We should definitely do something to make that easier! I think you need to put the certificate into `/etc/ssl/certs` with a name ending in `.pem`, and then run `c_rehash -v /etc/ssl/certs`

andyf: why not adopt OIs service, it simulates the behaviour of solaris 11.3...

andyf: github.com/OpenIndiana/oi-userland/…r/components/openindiana/smf-cacert

andyf: and github.com/openindiana/smf-cacert

andyf: thank you so much, I launched the 'c_rehash' and it worked!

when you put certificate into /etc/ssl/cert, you most probablt also need c_rehash or such

Agnar - thanks, looks useful!

I'm following illumos.org/docs/contributing/gerrit, but I fail on the step to scp the hook script: scp olafbohlen⊙cio:hooks/commit-msg .git/hooks/ # subsystem request failed on channel 0

Try adding `-O` to scp

ah right

switched to sftp

thanks for returning a favor :)

yay, that worked. the gerrit doc is phantastic btw,

very very clear instructions, a great example

so, if someone wants to review a 6lines code removal in emlxs_solaris.c: code.illumos.org/c/illumos-gate/+/3415 ;)

→ CODE REVIEW 3415: 16459 want emlxs to support Oracle branded LP adapters (NEW) | illumos.org/issues/16459

so I see it correctly that I now git commit --amend, add reviewers to the commit message and then prepare the RTI?

That sounds right. Some people also push again to gerrit and some others even set the integration ready bit, but it just generates more emails to people who are copied on it.

okies.

I'll re-run the built tonight, my previous built unfortunately contained mofifications somewhere else in the tree which I forgot to branch correctly, so I'll rebuilt to get a clean mail_msg

At some point in the future we can hopefully integrate through gerrit directly in which case the IA flag becomes useful.

ok, good to know

it's phantastic how pain can motivate you to learn about code contribution ;)

It's always great when somebody goes through the process for the first time too. It helps make sure the documentation is up to snuff.

andyf: I went through gerrit the first time, other contributions are already 7y ago :/

too much paid work to do

I use --amend mostly, and sometimes --author and --date is useful too;)

tsoome_: I actually looked at one of your commits for a template ;)

ouch:)

[illumos-gate] 16461 Introduce sequence to clear Branch History Buffer (BHB) -- Dan McDonald <danmcd⊙mi>

Hey, How can I use TSO/LRO in illumos? "dladm show-linkprop" doesn't show so much.

Is it supported in illumos?

if the driver supports iit, it should show up on dladm show-linprop -p lro <linkname>

at least for e1000g and ixgbe it seems not to be supported

So it looks like i40e doesn't support it at all?

The man pages list the supported features fwiw - illumos.org/man/4D/i40e

I don't know how much is plumbed up to dladm today.

seems i40e has LSO but not TSP/LRO

also, I have seen a lot of issues in the past with TSO on other operating systems btw...

and LSO is on by default

i'm not sure it's a dladm property and might just be a driver.conf property

but yeah, i believe it's enabled by default

I also don't believe the i40e hardware itself supports LRO

(though in general any hardware that does support LRO is going to have it disabled by default)

ok, git pbchk fails for me with: b"fatal: ambiguous argument 'origin/master..': unknown revision or path not in the working tree.\nUse '--' to separate paths from revisions, like this:\n'git <command> [<revision>...] -- [<file>...]'\n"

I guess I'm missing arguments, however illumos.org/docs/contributing doesn't specify anything precisly

If pbchk can't find the parent commit, you can specify what you're comparing against as the last argument.

So if you just have one commit, something like `git pbchk -p HEAD~` works

ah, it needs the previous commit

but usually you point it at the master branch from illumos-gate - in your case it's not finding origin/master which is usually where I'd expect it to be.

and what does it mean with: only complete workspaces may be pbchk'd

Looking at the code, you have an extra parameter at the end of the line that it doesn't like

which it's interpreting as [path...] and you can't specify paths with pbchk

hmm, where exactly?

What was your command?

git pbchk master

You missed the `-p`

git pbchk -p master

oh, me stupid

so it thought master was a filename

now it works :)

How bad was that file? :)

just missing copyright, but I will not put my copyright in it for deleting 6 lines ;)

Ah nice. Sometimes you make a small change like that and pbchk shows you things from everywhere else in the file (I think fixing most of them is optional but encouraged).

ah, yeah.

no, nothing - I send my mail to advocates

have

andyf: "dladm show-linkprop i40e5|grep lso" doesn't show anything. Or it is not supposed to be set on/off?

LSO is not managed via dladm

Yea, LSO is managed through the driver conf file (i40e.conf). And it's enabled by default unless you set tx_lso_enable to 0.

(That should probably be a private dladm(8) attribute using the private _<name> convention.)

(Unless it's something that can only be enabled/disabled at attach time.)

Good. The rest question is how to check whether it works or not ;)

vetal: One way to check is to use dtrace to see if `i40e_lso_chain()` is being called.

i _think_ it could probably be made a private dladm property (which means it doesn't show up unless you explicitly ask for it)

and remember that LSO doesn't really kick in if the application isn't trying to send large buffers

it looks like really just needs to be set/unset before m_start() is called

For the dladm prop you'll have to think about quiescence and how to deal with outstanding LSO mblks coming from userland. Though we do have generic LSO emulation code now, so that could help.

(it looks like mac will call m_getcapab to get LSO parameters after the instance is started, so you'd not want to toggle after it's started)

Agnar - the RTI message looks good to me but your mail_msg shows some build errors - possibly something around perl.

One thing rmustacc and I have talked about in years past is just saying _everything_ supports stuff like checksum offload and LSO. Then, if the driver doesn't actually support those features, you rectify it with emulation code just before handing the mblk off to the driver. If that were our world than I imagine we could just expose a standard dladm option in the case that we do want to turn those features off.

andyf: yes, a lot of perl. let me correct the perl patch and rebuild

I forgot to set the correct perl path

:/

I think it's safe to say that we've all done it!

Either perl or python anyway..

perl and python version problems are like 97% of all my build failures

it must be the p

perl...python...php...penguins... ;)

[illumos-gate] 16460 dmu_zfetch_stream_fini leaks refcount -- Andy Fiddaman <illumos⊙fn>

is there a way to see the various tcp socket options of a socket belonging to an arbitrary process (at least without a lot of mdb spelunking)?

pfiles?

ahh.. actually that does show what i wanted (once I fould find the actual fd amongst the noise :P)

trying to diagnose glacial zfs send perf, so trying to look at each piece along the way

oh wonderful, took 20s to remove 6 lines from a c file, now finding obscure perl bugs during build :)

make sure the version in your env file matches what's on the system

they don't always get updated when distros bump perl versions

that's usually what bites me, then i get upset for myself for having wasted 1-4 hours

err at myself

which should probably motivate me to update my 'theperlthe' branch :)

rzezeski: It looks like it should be improved somehow. For the instance Solaris has ability to modify LRO value via 'dladm set-linkprop'.

rzezeski: As I checked i40e_lso_chain() is called for output traffic. Is it possible to verify LRO is used for received traffic ?

AFAIK i40e doesn't support LRO.. as in the actual hardware itself doesn't support it

just send

which is kinda surprising consider how much kitchen sink stuff it does have :)

[illumos-gate] 16464 Typo in i40e(4D) -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 16463 zfs_ioc_recv leaks nvlist -- Andy Fiddaman <illumos⊙fn>

I've thought about writing up an ipd around better dynamic control of those properties and the resulting GLD APIs we'd want.

vetal: As jbk mentioned, the 700-series parts do not support hardware LRO.

And I think we want to use the software LRO stuff we prototyped anyways as that simplifies a lot of the driver chicanery involved.

As then you have internal timers that it's using to decide when to merge and having to figure out how to get up to 64 KiB buffers consumed.

Yes, it seems better if we just had a generic LRO feature in mac that all drivers can take advantage of.