[00:59:49] *** Quits: ziyeyang_ (~ziyeyang@192.55.54.38) (Quit: Leaving) [01:45:20] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Ping timeout: 260 seconds) [02:35:59] *** Joins: tkulasek (86bfdc47@gateway/web/freenode/ip.134.191.220.71) [02:42:00] *** Joins: tkulasek_ (tkulasek@nat/intel/x-gvbmnododdijnmvd) [02:48:20] *** Quits: tkulasek (86bfdc47@gateway/web/freenode/ip.134.191.220.71) (Quit: Page closed) [02:53:10] *** Quits: sbasierx (sbasierx@nat/intel/x-hmtvthremkqgdoaw) (Quit: Going offline, see ya! (www.adiirc.com)) [02:56:58] *** Joins: sbasierx (sbasierx@nat/intel/x-fbwxqabfrlpmyxgh) [02:59:31] *** Quits: sbasierx (sbasierx@nat/intel/x-fbwxqabfrlpmyxgh) (Client Quit) [03:03:36] *** Joins: sbasierx (sbasierx@nat/intel/x-ouzxrvgazrfpyfwg) [03:27:28] *** Quits: tkulasek_ (tkulasek@nat/intel/x-gvbmnododdijnmvd) (Quit: Leaving) [03:27:38] *** Joins: tkulasek_ (~tkulasek@134.134.139.73) [04:06:28] *** Quits: tkulasek_ (~tkulasek@134.134.139.73) (Quit: Leaving) [04:07:00] *** Joins: tkulasek_ (~tkulasek@192.55.54.44) [04:07:33] *** Quits: tkulasek_ (~tkulasek@192.55.54.44) (Client Quit) [04:08:00] *** Joins: tkulasek (~tkulasek@134.134.139.73) [05:18:04] *** Quits: sbasierx (sbasierx@nat/intel/x-ouzxrvgazrfpyfwg) (Quit: Going offline, see ya! (www.adiirc.com)) [05:21:12] *** Quits: tkulasek (~tkulasek@134.134.139.73) (Remote host closed the connection) [05:43:37] *** Joins: johnmeneghini (~johnmeneg@216.240.30.5) [05:48:38] *** Quits: johnmeneghini (~johnmeneg@216.240.30.5) (Quit: Leaving.) [07:39:19] reminder: Asia timezone friendly community meeting is a little over 13 hrs away... see info at http://www.spdk.io/community/ [08:17:42] *** Joins: tkulasek (tkulasek@nat/intel/x-pcqvoyuceahudeog) [08:51:09] drv jimharris: pls review DPDK 18.02 patches? [08:58:23] drv: please review DPDK 18.02 patches? :-) [08:58:32] i'll try to take a look later today [09:13:38] jimharris: https://review.gerrithub.io/#/c/401647/ seems to have broken the pool. I didn't realize this before, but /var/tmp doesn't get purged at reboot, so when a build fails, some of those files will be left behind. [09:15:44] I will start working on a fix to make our cleanup code more robust. [09:24:44] Seth, I am getting a failure on patch https://review.gerrithub.io/#/c/400160/ that looks like its happening on the DPDK build [09:24:46] if (vfio_group_fd > 0) { [09:24:46] ^ [09:24:51] default: [09:24:53] ^~~~~~~ [09:24:55] by . For historical compatibility, it is [09:24:57] currently defined by as well, but we plan to [09:24:59] remove this soon. To use "makedev", include [09:25:01] directly. If you did not intend to use a system-defined macro [09:25:03] "makedev", you should undefine it after including . [-Werror] [09:25:05] dev = makedev(major, minor); [09:25:07] ^~~~~~~~~~~~~~~~~ [09:25:14] CC eal_common_options.o [09:25:16] cc1: all warnings being treated as errors [09:25:18] make[8]: *** [/home/sys_sgsw/build_pool/agent/repo/dpdk/mk/internal/rte.compile-pre.mk:140: eal_vfio.o] Error 1 [09:25:21] make[8]: *** Waiting for unfinished jobs.... [09:25:23] CC eal_common_thread.o [09:25:25] CC eal_common_proc.o [09:25:27] cc1: all warnings being treated as errors [09:25:29] make[8]: *** [/home/sys_sgsw/build_pool/agent/repo/dpdk/mk/internal/rte.compile-pre.mk:138: eal_pci_uio.o] Error 1 [09:25:32] make[7]: *** [/home/sys_sgsw/build_pool/agent/repo/dpdk/mk/rte.subdir.mk:63: eal] Error 2 [09:25:34] make[6]: *** [/home/sys_sgsw/build_pool/agent/repo/dpdk/mk/rte.subdir.mk:63: linuxapp] Error 2 [09:25:36] make[5]: *** [/home/sys_sgsw/build_pool/agent/repo/dpdk/mk/rte.subdir.mk:61: librte_eal] Error 2 [09:25:38] make[4]: *** [/home/sys_sgsw/build_pool/agent/repo/dpdk/mk/rte.sdkbuild.mk:80: lib] Error 2 [09:25:40] make[3]: *** [/home/sys_sgsw/build_pool/agent/repo/dpdk/mk/rte.sdkroot.mk:127: all] Error 2 [09:25:44] make[3]: Leaving directory '/home/sys_sgsw/build_pool/agent/repo/dpdk' [09:25:46] make[2]: *** [Makefile:12: all] Error 2 [09:25:48] make[1]: *** [Makefile:79: all] Error 2 [09:25:50] make: *** [/home/sys_sgsw/build_pool/agent/repo/mk/spdk.subdirs.mk:35: dpdkbuild] Error 2 [09:25:52] I rebased before checking in the patch [09:28:03] Thanks John, I'll take a look. I think that I have run into something similar before. [09:38:05] cool. Let me know what you find out [09:48:03] drv: should we revert the ceph cleanup patch then until sethhowe resolves the cleanup issue? [09:53:40] jimharris: I think that https://review.gerrithub.io/#/c/401860/ and https://review.gerrithub.io/#/c/401857/ should do it. running them now. [09:58:05] peluse: attempting to confirm my understanding, the SPDK group has a community meeting weekly with the Euro one every other Tuesday (formerly Thurs, so next Euro one is 6 March) at UTC 15:00-16:00, and the Asia one every other Thursday (today, 28 Feb) at UTC 04:00-05:00? [10:06:01] peluse: owing to the time zone diff's, I think I made that a little confusing. The Asia one (I think) is indeed every Thursday, so the next one for Thurs (28 Feb) at UTC 04:00-05:00 results in it appearing "today" (Wed) for those of us in the United States who want to participate in the call. [10:20:27] *** Joins: Param (~Param@106.208.12.120) [10:23:00] https://ci.spdk.io/spdk/builds/review/330421536fa0b9bf15000a896f764dd582c5c508.1519805228 [10:23:15] I am not able to access the link as there was a build failure.. [10:23:50] This is my patch https://review.gerrithub.io/c/401314/3 [10:29:54] *** Quits: Param (~Param@106.208.12.120) (Ping timeout: 260 seconds) [10:42:25] *** Quits: tkulasek (tkulasek@nat/intel/x-pcqvoyuceahudeog) (Ping timeout: 248 seconds) [11:47:23] *** Joins: felipef (~felipef@62.254.189.133) [11:47:30] *** felipef is now known as felipefr [11:54:59] jkkariu: It looks like in patch set 2 of https://review.gerrithub.io/#/c/400160/ the dpdk submodule got switched to the wrong version and that is what caused the failure. When you pull from master, the submodule doesn't update automatically, so every time when I pull from master, I will run git submodule update --init --recursive just to make sure I am on the right dpdk branch when I rebase later. [12:08:15] *** Quits: lhodev (~Adium@66-90-218-190.dyn.grandenetworks.net) (Quit: Leaving.) [12:09:03] *** Joins: lhodev (~Adium@inet-hqmc06-o.oracle.com) [12:32:41] drv: could we have a separate github/dpdk branch for 2mb hugepages? [12:33:25] 2mb hugepage support for virtio, I mean* [13:21:45] *** Quits: felipefr (~felipef@62.254.189.133) (Quit: Leaving...) [13:53:22] *** Quits: guerby (~guerby@april/board/guerby) (Ping timeout: 260 seconds) [13:58:41] *** Joins: guerby (~guerby@april/board/guerby) [14:11:40] *** Quits: sethhowe (~sethhowe@134.134.139.72) (Remote host closed the connection) [14:12:23] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [14:21:14] *** Joins: sethhowe (~sethhowe@192.55.54.42) [14:37:17] thank you seth [14:54:11] *** Quits: lhodev (~Adium@inet-hqmc06-o.oracle.com) (Remote host closed the connection) [14:57:30] *** Joins: lhodev (~Adium@66-90-218-190.dyn.grandenetworks.net) [15:41:48] *** Quits: sethhowe (~sethhowe@192.55.54.42) (Remote host closed the connection) [15:43:50] *** Joins: sethhowe (~sethhowe@192.55.54.42) [15:51:20] lhodev, sorry was away for a bit. Yeah, best to use a UTC converter to figure out which day it is, there's not much I can do about that since today isn't today for everyone but Thu 04:00 UTC for example is the same for everyone [15:51:39] but yeah regardless of where you are, it is in about 5 hours from now :) [15:54:20] peluse: thx Paul [16:16:10] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [16:37:26] *** Joins: Param (~Param@106.208.6.64) [16:43:37] bwalker: Ben, as you're probably aware, I've been working on the effort to replace, where possible, uses of exit() in lib code with return() instead. I've got one series already merged upstream and another pending review. Meanwhile, I started looking at the exit()'s in lib/net/interface.c. That's looking like an altogether huge beast to resolve as it involves the spdk_subsystem_XXXX code. I'd have to alter the .init function point [16:43:38] er member to return an int — it's now a void — and then tackle all of the instances of the various subsystems using it, the error-paths, etc. Before I undertake such an endeavor, I'd like to float an open query here on the IRC whether this is something we want/should do, and if so, whether there's a target time-frame for doing such a sweeping change. [16:44:41] I am not able to view this page.. https://ci.spdk.io/spdk/builds/review/330421536fa0b9bf15000a896f764dd582c5c508.1519805228 [16:45:10] This is the results page of SPDK automated system [16:47:24] Param: I've observed that kind of thing happen before where the build results link wasn't accessible, and it wasn't due to having been removed due to aging. I think you'll need to get one of the maintainers to re-launch the build. [16:50:33] Sure.. Thanks.. [16:51:14] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Ping timeout: 260 seconds) [16:54:11] lhodev, FYI bwalker is on sabbatical... but sometimes still in the channel for some reason :) [16:54:48] I'm not super familiar with that code but yeah if its a huge effort get an opinion from one of the other maintainers first I'd say [16:55:11] peluse: Thanks for the heads up Paul. [17:07:16] lhodev: are you referring to the two exit() calls in spdk_process_new_interface_msg? [17:14:17] jimharris: yes, spdk_process_new_interface_msg(). [17:18:16] *** Quits: Param (~Param@106.208.6.64) (Quit: Param) [17:19:15] jimharris: Jim, if I'm interpreting the code properly, I believe that's only reachable via the spdk_subsystem registration and initialization flow. [17:19:20] try just returning -1 there instead of exit() (and change return type of that function) [17:19:23] and then [17:20:12] propagate that return value back so that it gets returned from spdk_prepare_ifc_list() [17:20:36] and then propagate that return value back so that it gets returned from spdk_interface_init [17:21:27] then in spdk_interface_init, get the return value from spdk_prepare_ifc_list() and progagate that back to the caller too [17:21:28] Right, and that just goes to spdk_interface_init()….yes, and that comes from spdk_interface_subsystem_init() which in turn is registered via the SPDK_SUBSYSTEM_REGISTER() [17:22:30] right - but once that return value gets propagated back to spdk_interface_subsystem_init(), it will get passed to spdk_subsystem_init_next() - this is the signal that the subsystem code should proceed to the next subsystem [17:22:59] but once you pass -1 there, spdk will stop initializing more subsystems and prepare to exit [17:23:19] well...not exit directly but you know what I mean [17:23:28] Right, but the SPDK_SUBSYSTEM_REGISTER() relies on a data structure that instantiates all such init's of subsystems as type void so altering that would affect all spdk subsystems. [17:24:40] spdk_interface_subsystem_init() does not return a value in the normal sense - it returns the value through the spdk_subsystem_init_next() call [17:26:13] spdk_subsystem_init_next() invokes the .init members of each subsystem all of which are type void so I don't understand what you mean by "returns the value". [17:27:36] the first thing it does is look at the rc that was passed as a parameter [17:29:13] spdk_interface_subsystem_init() would call spdk_subsystem_init_next(-1) if there is an error, then spdk_subsystem_init_next() will call spdk_app_stop() instead of calling the init function for the next subsystem [17:30:23] I see that, but I'm more focused on the line g_next_subsystem->init(). I was focusing on the ability to get a return value there from that init call, but since it's a void (currently) we don't have the opportunity to return the failure. [17:31:36] this is all asynchronous - so g_next_subsystem->init() gets called and returns immediately [17:32:40] in this specific case, spdk_subsystem_init_next() calls spdk_interface_subsystem_init() which will in turn recursively call spdk_subsystem_init_next() again with the error code [17:33:40] it might make more sense if you add some debug prints in spdk_subsystem_init_next() - print g_next_subsystem->name just before the init() call is made, and then again at the top of the function before it evaluates the rc code [17:34:45] we have some subsystems that have to do a bunch of asynchronous work in the background - for example, the bdev layer has to do a bunch of disk reads to identify blobstore metadata [17:34:59] and that's what drove this interface [17:35:48] jimharris: ok, I'll try that, or run one of the app's with gdb. This code ultimately gets kicked off from an spdk_app_start(). I'm particularly intrigued of your mention that this is done asynchronously as I've not (yet) moved upward to see where there's a thread or anything that's launched that would, in theory, provide the asynchronous execution. [17:36:42] the reactors have all started at this point, and modules such as nvme would register pollers that would drive the asynchronous completions [17:38:03] I'll play with it. Get a feel for how it works with gdb instead of just static code inspection. Meanwhile, about my other lib/exit series that is awaiting review….. ;-) [19:10:40] *** Joins: ziyeyang_ (~ziyeyang@192.55.54.40) [20:01:42] *** Joins: ziyeyang__ (~ziyeyang@192.55.54.40) [20:01:42] *** Quits: ziyeyang_ (~ziyeyang@192.55.54.40) (Remote host closed the connection) [20:58:11] Community meeting about to start... WebEx at http://www.spdk.io/community/ [21:01:16] jimharris and whoever else highlighted me earlier: sorry, didn't see your messages (was traveling today) - I'm reading the backlog now [21:01:36] drv: yeah - forgot about that until seth reminded me [21:10:01] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [21:14:36] *** Joins: Shuhei_ (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [21:16:15] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Quit: Page closed) [21:24:58] *** Parts: Shuhei_ (caf6fc61@gateway/web/freenode/ip.202.246.252.97) () [21:25:53] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [21:30:01] jimharris, made good progress on crypto vbdev following the additional discussion this morn.. thanks. Will be ready to try encrypting stuff this week I think [21:31:15] (lots of details to decide on, will post some stuff to trello after I get them all listed out) [21:35:29] awesome! [21:36:08] yes - rpcs and other stuff will need to get worked out but if you have the data path working and the dpdk stuff all linked in those are the most complex hurdles I think [22:06:18] Hi Ziye, Jim, I would like to share with you that I observed calsoft failed https://ci.spdk.io/spdk/builds/review/71055d95a63a37dd74b54ae6901f5f245c59f794.1519879379/. [23:35:21] Hi Shuhei [23:35:46] Does it related my merged patch, today? [23:38:00] Can you rebase your patch with the master branch, and see whether it happens again? [23:39:24] It seems like a no channel error when doing block spdk_bdev_readv_blocks [23:56:56] *** Joins: sbasierx (~sbasierx@192.198.151.44) [23:57:07] I will keep watching if this issue is repeated.