[00:49:02] *** Joins: tkulasek (tkulasek@nat/intel/x-ydmajmmnnnddvvkj) [06:45:57] bwalker, I did all that error path cleanup stuff in crypto, went with gotos though as there was one func with too many local dependencies, got pretty ugly to to be consistent with the other funcs just used gotos everywhere. Came out OK.... [11:27:43] *** Quits: tkulasek (tkulasek@nat/intel/x-ydmajmmnnnddvvkj) (Ping timeout: 260 seconds) [12:55:30] *** Quits: peluse (peluse@nat/intel/x-ztzgkgdgpvivxgfo) (Ping timeout: 256 seconds) [13:25:46] cool sounds good peluse [14:02:14] darsto: you there? [14:02:33] bwalker: + [14:02:42] I'm trying to run with DPDK 18.08 and I don't think the patches from spdk-18.05 have been ported over to the spdk-18.08 branch yet [14:02:46] does that sound right? [14:03:05] I want to reproduce the dynamic memory issue you reported [14:03:09] they're waiting on gerrithub [14:03:18] can you link me [14:03:28] top here: https://review.gerrithub.io/c/spdk/dpdk/+/422772/1 [14:04:26] so if I grab that series and build, then pass -1 for the memory size (or leave it off) [14:04:30] it will do dynamic memory allocation, right? [14:04:54] -1 won't work [14:04:56] 0 will [14:05:13] doesn't 0 mean "all" memory? [14:05:18] as opposed to dynamic [14:05:24] i changed that very recently [14:05:30] < 0 means "all" [14:05:51] ok [14:05:59] so I fetched the top of your series [14:06:03] then hit make in spdk [14:06:11] and it is tellin gme it doesn't have defconfig_spdk-linuxapp-gcc [14:06:12] ah, that won't work [14:06:16] yeah [14:06:39] so I need to manually build dpdk? [14:06:41] I still have to update our makefiles [14:06:56] yep, make config T=x86_64-native-linuxapp-gcc [14:07:00] ok [14:11:45] ok cool I reproduced it [14:11:55] it's pretty neat seeing it claim hugepages as you create subsystems and such [14:14:14] agreed, codewise that's a nice piece of work as well [14:38:57] so what's going on in the nvmf target is that we create our own memory map [14:39:14] that maps vaddrs to rdma memory regions - you have to pre-reg memory with the RDMA NIC [14:39:42] so I put in some prints each time our memory map is notified or new memory being registered vs. memory being unregistered [14:40:49] I see one registration upon creation of the memory map for vaddr 0x7ffbe8400000, size 427819008 [14:41:09] so we register that with the RNIC and it is associated with the RDMA MR 0x9fcab0 [14:41:34] then when Malloc0 gets deleted, we get a memory unregistration notification [14:41:59] for 0x7ffbf5400000, size 69206016 [14:42:11] which also releases the RDMA MR [14:42:17] and then this happens again when Malloc1 gets deleted [14:42:45] so the challenge is that the memory is registered in different chunks than it is unregistered in [14:43:19] so either I have to implement a bunch of code to track when I can really free an RDMA MR [14:43:31] or we need to try to unregister memory in the same units it was registered in [14:45:49] darsto: I think the difference may be the use of rte_memseg_contig_walk vs rte_memseg_walk [14:52:48] no it looks like we're intentionally coalescing the notifications across virtually contiguous regions [14:52:56] in our memory map code [14:56:51] well, I think there are two different directions we could go here [14:57:25] we could either do notifies on the memory maps in the allocation units that dpdk is using underneath (i.e. the memory segments) [14:58:21] or I could potentially try to place games with ibv_rereg_mr to change a registration on the fly. I worry primarily about punching holes in a registered region with that approach though. [15:08:04] if we try to do memory registrations in the units that DPDK does them, that breaks vhost [15:08:10] because the memory isn't even registered by DPDK to begin with [15:08:18] quite a predicament here [15:52:28] darsto: https://review.gerrithub.io/#/c/spdk/spdk/+/422913/ [16:17:33] bwalker: so what actually happens after we free some memory without unregistering it? [16:32:56] *** Parts: lhodev (~lhodev@66-90-218-190.dyn.grandenetworks.net) ("Textual IRC Client: www.textualapp.com") [16:33:44] *** Joins: lhodev (~lhodev@66-90-218-190.dyn.grandenetworks.net) [17:57:16] *** Joins: travis-ci (~travis-ci@ec2-54-156-68-163.compute-1.amazonaws.com) [17:57:17] (spdk/master) bdev/lvol: using spdk_bdev_alias_del_all() to delete all alias on destroy (wuzhouhui) [17:57:17] Diff URL: https://github.com/spdk/spdk/compare/b5616804dc9b...6deac3e66093 [17:57:17] *** Parts: travis-ci (~travis-ci@ec2-54-156-68-163.compute-1.amazonaws.com) () [17:57:49] *** Joins: travis-ci (~travis-ci@ec2-54-162-244-207.compute-1.amazonaws.com) [17:57:50] (spdk/master) doc/blob: fix typo errors (Chen Zhenghua) [17:57:50] Diff URL: https://github.com/spdk/spdk/compare/6deac3e66093...b07d3bd2bdb4 [17:57:50] *** Parts: travis-ci (~travis-ci@ec2-54-162-244-207.compute-1.amazonaws.com) () [18:08:15] *** Quits: wzh (~wzh@114.255.44.139) (Quit: WeeChat 1.9.1) [18:11:58] *** Quits: guerby (~guerby@april/board/guerby) (Ping timeout: 256 seconds) [18:14:27] *** Joins: guerby (~guerby@april/board/guerby)