05:24:50 <sjorge> I see i40e keeps on giving gifts to danmcd :(
05:26:42 <jbk> oh to everyone
05:27:19 <jbk> a lot of our stuff have them in there
16:03:14 <sjorge> Sadly my main server at home has them on the motherboard too :(
16:03:23 <sjorge> ixgbe been treating me way better
16:08:11 <jbk> hrm.. silly question.. in a number of .s files, we seem to define certain instructions using .byte vs. teh symbolic name, is that just a case of 'older compilers didn't know about it', or was there some other reason
16:08:58 <jbk> (e.g. `.byte 0x0f, 0x01, 0xf9` vs. `rdtcp`)
16:09:10 <jbk> err rdtscp
17:47:59 <pmooney> pretty certain that was to accomodate older compilers
17:48:06 <pmooney> presumably studio & friends?
17:54:53 <jclulow> Yeah it'll be for old tools that did not have a way to symbolically assemble those things
17:55:29 <jclulow> If the current gas we're using is able to deal with the instruction I don't think there is any reason to keep doing it
19:50:41 <jbk> hrm.. this seems likely obvious in restrospect, but I'm guessing that when BUS_UNCONFIGURE_{ONE,ALL} is called, that means the relevant child[ren] have already had their detach methods called..
19:50:47 <jbk> at least if i'm reading this correctly
20:06:03 <jclulow> jbk: I would think they probably had to have had that, yes
20:06:11 <jclulow> Because detach is fallible
20:06:33 <jclulow> If I refuse to detach, I don't think my parent should unconfigure me
20:18:11 <yuripv> sound like poor upbringing
20:18:21 <jclulow> ha
20:21:04 <jbk> haha
20:27:28 <frkzoid> pfexec dr_phil
20:45:08 <gitomat> [illumos-gate] 15009 Update tzdata to 2022d -- Andy Fiddaman <illumos⊙fn>
21:01:14 <Smithx10> lol
21:52:37 <gitomat> [illumos-gate] 15010 September 2022 hwdata update -- Andy Fiddaman <illumos⊙fn>
22:09:10 <jbk> oh interesting..
22:09:17 <jbk> if i'm understanding this table correctly
22:09:24 <jbk> then my idea is maybe not so horrible
23:12:46 <sjorge> famous last words?
23:13:37 <jbk> just what i mentioned on the i40e on the list
23:14:02 <jbk> at least according to the x710 programming guide, it claims that intels drivers for other os's use power of two sized buffers
23:52:45 <jclulow> It would definitely be better if the device was able to pool buffers for use with many different concurrent classification filters
23:52:57 <jclulow> and also to combine buffers so that they don't all have to be full MTU sized
23:53:10 <jclulow> seems like if you're going to make a NIC this complex, it should at least be able to manage that