[illumos-gate] 16050 zpool import crash due to duplicate path from readdir() -- Andy Fiddaman <illumos⊙fn>

jbk: gmssl is BSD license, it is compatible with CDDL

then i don't see anything that'd stop adding it... just a matter of someone wanting to do the work

For the nprom_multi property, wat would be considered multicast traffic? Anything from the multicast IP ranges? Or is it based on the multicast MAC addreses? Or something else entirely?

sjorge: It looks to me like that's a GLDv2 property, so not something that probalby comes up much. Where are you seeing that?

I was trying to figure out to what exactly the bhyve viona promiscmulti and promiscsap properties map to

The others were somewhat clear

I tracked down promiscmulti to allowing traffic where nprom_multi is set

But it's unclear to me what exactly would set it

nprom_multi shouldn't be showing up for most devices these days?

But can you point me to which bit of code in there you're referring to in bhyve?

I ask because viona doesn't actually use STREAMS here, it just sets the MAC levels via the kernel, if I'm reading pci_viona_eval_promisc() correctly.

[illumos-gate] 15969 High mutex contention with SMB calling ZFS access check -- Gordon Ross <gwr⊙rc>

So was was trying to work back from github.com/omniosorg/zadm/blob/1fbc…/lib/Zadm/Schema/Bhyve.pm#L204-L209 -> github.com/omniosorg/illumos-omnios…md/bhyve/net_backends.c#L1068-L1075 -> github.com/omniosorg/illumos-omnios…/usr/src/uts/common/sys/dlpi.h#L392

which brough me github.com/omniosorg/illumos-omnios…src/uts/common/io/gld.c#L4854-L4858 ... and there I got lost trying to figure out what nprom_multi was

Me having taking a wrong turn somewhere is also likely

I'm mostly interested in what would be considered multicast traffic for viona, just the IPs that are in the mulicast class or not. IIRC there are also some MACs that are considered multicast.

yes there are multicast layer2 addresses. What does nprom_multi deal with? layer2 or layer3 ?

* Work out what request (if any) has to be made to the MAC layer

^ a comment a few lines above. Looks like it's layer2.

sjorge: I'm not sure if that is actually used for viona or not. My expectation is that we're not using libdlpi because we're using viona and instead you're using the viona interfaces.

So, the dlpi path doesn't end up in the GLDv2 code there.

Initially a dlpi request to turn on promiscuous mode ends up at proto_promiscon_req() in dld_proto.c. That goes to dls_promisc() in uts/common/io/dls/dls.c, which makes a request directly to MAC.

So the DLPI promisc levels equate logically as: please give me a packet if it happens to be multicast based on what's defined for the lower level. Because we're using ethernet, that means it has an Ethernet multicast mac address.

SAP stands for service attachment point. It's a bit of a baroque term from DLPI. The way I think about it (and maybe danmcd can correct me where I stray) is that the main point of DLPI was to multiplex L2. In our case, that's basically an Ethertype.

Based on this you can see that if you actually turn on the SAP, we translate that into mac by not turning on the underlying promisc mode in the card.

I have not found a case where things in gld.c still apply. I know that softmac is intended to help bridge th gap, but I'm not 100% certain since it just rarely has ever come up with anything I've dealt with.

ok so layer 2 multicast traffic :3 that what i was looking for

so the SAP grabs the vlans without putting the NIC in promisc (physical nic)

?

It's a little more nuanced than that, but basically it's only going to get traffic that the stack was using. But I don't believe viona has anything to do with the DLPI usage.

Because viona would fight with libdlpi over the device.

thanks for the info, it got very confusing very quickly while i was looking around

i don't suppose anyone's intimately familiar with KCF? :)

i _think_ i've maybe identified the issue, but the design here seems rather involved, and I suppose there's a question about intention

i think I can explain how kcf_get_mech_provider() can return stale provider info (which will likely cause a panic), but not sure how it's supposed to work

No, but I might be able to provide another pair of eyes next week if it'd help jbk.