00:14:38 [illumos-gate] 16050 zpool import crash due to duplicate path from readdir() -- Andy Fiddaman 01:08:29 jbk: gmssl is BSD license, it is compatible with CDDL 01:43:31 then i don't see anything that'd stop adding it... just a matter of someone wanting to do the work 10:18:53 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? 15:13:27 sjorge: It looks to me like that's a GLDv2 property, so not something that probalby comes up much. Where are you seeing that? 16:13:24 I was trying to figure out to what exactly the bhyve viona promiscmulti and promiscsap properties map to 16:13:28 The others were somewhat clear 16:13:52 I tracked down promiscmulti to allowing traffic where nprom_multi is set 16:13:58 But it's unclear to me what exactly would set it 16:28:32 nprom_multi shouldn't be showing up for most devices these days? 16:30:05 But can you point me to which bit of code in there you're referring to in bhyve? 16:33:15 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. 17:14:34 [illumos-gate] 15969 High mutex contention with SMB calling ZFS access check -- Gordon Ross 17:25:51 So was was trying to work back from https://github.com/omniosorg/zadm/blob/1fbc4ce7d3f07a682f54d2b7486de9aa1ae32a37/lib/Zadm/Schema/Bhyve.pm#L204-L209 -> https://github.com/omniosorg/illumos-omnios/blob/6514c9b6c153ce810715c6e05c4b0d47a227d0ad/usr/src/cmd/bhyve/net_backends.c#L1068-L1075 -> https://github.com/omniosorg/illumos-omnios/blob/6514c9b6c153ce810715c6e05c4b0d47a227d0ad/usr/src/uts/common/sys/dlpi.h#L392 17:27:02 which brough me https://github.com/omniosorg/illumos-omnios/blob/6514c9b6c153ce810715c6e05c4b0d47a227d0ad/usr/src/uts/common/io/gld.c#L4854-L4858 ... and there I got lost trying to figure out what nprom_multi was 17:28:43 Me having taking a wrong turn somewhere is also likely 17:30:20 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. 17:31:29 yes there are multicast layer2 addresses. What does nprom_multi deal with? layer2 or layer3 ? 17:40:16 * Work out what request (if any) has to be made to the MAC layer 17:40:31 ^ a comment a few lines above. Looks like it's layer2. 18:47:19 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. 18:47:41 So, the dlpi path doesn't end up in the GLDv2 code there. 18:49:35 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. 18:50:37 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. 18:52:36 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. 18:53:16 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. 18:55:01 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. 19:37:36 ok so layer 2 multicast traffic :3 that what i was looking for 19:38:15 so the SAP grabs the vlans without putting the NIC in promisc (physical nic) 19:38:18 ? 19:42:24 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. 19:42:40 Because viona would fight with libdlpi over the device. 19:44:03 thanks for the info, it got very confusing very quickly while i was looking around 20:20:23 i don't suppose anyone's intimately familiar with KCF? :) 20:22:31 i _think_ i've maybe identified the issue, but the design here seems rather involved, and I suppose there's a question about intention 20:25:47 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 20:52:54 No, but I might be able to provide another pair of eyes next week if it'd help jbk.