[01:03:11] *** Joins: mbjorling (~silverwol@95-166-82-66-cable.dk.customer.tdc.net) [03:46:25] *** Joins: lhodev_ (~lhodev@66-90-218-190.dyn.grandenetworks.net) [03:46:37] *** Quits: lhodev (~lhodev@66-90-218-190.dyn.grandenetworks.net) (Ping timeout: 244 seconds) [03:51:49] *** Joins: lhodev (~lhodev@66-90-218-190.dyn.grandenetworks.net) [03:53:13] *** Quits: lhodev_ (~lhodev@66-90-218-190.dyn.grandenetworks.net) (Ping timeout: 260 seconds) [06:27:07] jimharris: Eager to see your patches on how you resolved the dependencies. With respect to gerrit, do you have a way of adding your patches atop my patch series so they remain all related? [06:41:53] Also, given the apparent difference in linking behavior you saw on your system (with later revs of gcc/binutils than mine), I'm eager to see when I apply the patches if it'll all build cleanly for me. [06:47:12] *** Joins: lhodev_ (~lhodev@inet-hqmc08-o.oracle.com) [06:47:57] *** Quits: lhodev (~lhodev@66-90-218-190.dyn.grandenetworks.net) (Ping timeout: 240 seconds) [07:55:18] *** Parts: lhodev_ (~lhodev@inet-hqmc08-o.oracle.com) ("Textual IRC Client: www.textualapp.com") [07:55:56] *** Joins: lhodev (~lhodev@inet-hqmc08-o.oracle.com) [08:20:18] jimharris: peluse: https://review.gerrithub.io/c/spdk/spdk/+/421556 [08:57:32] *** Joins: waelhalbawi (94571704@gateway/web/freenode/ip.148.87.23.4) [09:02:06] *** Quits: waelhalbawi (94571704@gateway/web/freenode/ip.148.87.23.4) (Ping timeout: 252 seconds) [09:19:58] lhodev: i think we can probably just get my patches in first - they don't harm existing static linking - and then you can rebase your series on top of my patches [09:40:00] lhodev: series of 5 patches fixing up some dependencies (and adding rte_vhost_* to map file) ends here: https://review.gerrithub.io/#/c/spdk/spdk/+/422442/ [09:46:19] jimharris: Thx Jim. Will take a look. [09:47:40] *** Joins: waelhalbawi (a02259ed@gateway/web/freenode/ip.160.34.89.237) [10:37:50] *** Joins: travis-ci (~travis-ci@ec2-54-91-111-0.compute-1.amazonaws.com) [10:37:51] (spdk/master) test: refactor the run_test function to add detailed information (Chen Wang) [10:37:51] Diff URL: https://github.com/spdk/spdk/compare/57a5c6020bb7...1f0bff73df6c [10:37:51] *** Parts: travis-ci (~travis-ci@ec2-54-91-111-0.compute-1.amazonaws.com) () [10:39:35] *** Joins: travis-ci (~travis-ci@ec2-54-91-111-0.compute-1.amazonaws.com) [10:39:36] (spdk/master) vhost: fix the coredump when perform live migration (Changpeng Liu) [10:39:36] Diff URL: https://github.com/spdk/spdk/compare/1f0bff73df6c...376be52bb02d [10:39:36] *** Parts: travis-ci (~travis-ci@ec2-54-91-111-0.compute-1.amazonaws.com) () [10:42:33] *** Joins: travis-ci (~travis-ci@ec2-54-91-111-0.compute-1.amazonaws.com) [10:42:34] (spdk/master) bdev/malloc: remove blocklen power of 2 restriction (Jim Harris) [10:42:34] Diff URL: https://github.com/spdk/spdk/compare/c8fd001075f4...b8a05080e00d [10:42:34] *** Parts: travis-ci (~travis-ci@ec2-54-91-111-0.compute-1.amazonaws.com) () [10:44:33] sethhowe: can you take a look at https://review.gerrithub.io/#/c/spdk/spdk/+/422204/ [10:47:21] *** Joins: travis-ci (~travis-ci@ec2-54-166-130-32.compute-1.amazonaws.com) [10:47:22] (spdk/master) doc/performance_report: add NVMe-oF performance report (John Kariuki) [10:47:23] Diff URL: https://github.com/spdk/spdk/compare/376be52bb02d...f85f70b40a57 [10:47:23] *** Parts: travis-ci (~travis-ci@ec2-54-166-130-32.compute-1.amazonaws.com) () [10:48:23] *** Joins: travis-ci (~travis-ci@ec2-54-166-130-32.compute-1.amazonaws.com) [10:48:24] (spdk/master) iscsi: fix the primary iscsi task free in queued_datain_tasks (Ziye Yang) [10:48:24] Diff URL: https://github.com/spdk/spdk/compare/f85f70b40a57...c8fd001075f4 [10:48:24] *** Parts: travis-ci (~travis-ci@ec2-54-166-130-32.compute-1.amazonaws.com) () [10:48:42] *** Joins: travis-ci (~travis-ci@ec2-54-166-130-32.compute-1.amazonaws.com) [10:48:43] (spdk/master) autotest: add unmap,flush,reset testing for iscsi initiator. (xuhuagen) [10:48:43] Diff URL: https://github.com/spdk/spdk/compare/b8a05080e00d...9f6b1099e549 [10:48:43] *** Parts: travis-ci (~travis-ci@ec2-54-166-130-32.compute-1.amazonaws.com) () [10:49:46] *** Joins: travis-ci (~travis-ci@ec2-54-91-111-0.compute-1.amazonaws.com) [10:49:47] (spdk/master) env/dpdk: allow 0 requested memory size (Dariusz Stojaczyk) [10:49:48] Diff URL: https://github.com/spdk/spdk/compare/9f6b1099e549...75327bc67e9a [10:49:48] *** Parts: travis-ci (~travis-ci@ec2-54-91-111-0.compute-1.amazonaws.com) () [10:50:10] jimharris: Jim, I applied your patches and rebased mine atop them, then "un-did" the push/pop/Bstatic changes in spdk.app.mk and spdk.modules.mk. A new build however yielded the dentical (first) link failure: examples/bdev/hello_world/hello_bdev. Same complaint of refs in libspdk_bdev_virtio that should've been resolved by the very next lib specified, libspdk_spdk_virtio. It must be my version of gcc/binutils. Am going to see if I can [10:50:11] obtain/build with more recent versions of those. [11:12:44] *** Joins: travis-ci (~travis-ci@ec2-54-166-130-32.compute-1.amazonaws.com) [11:12:45] (spdk/master) scripts/vagrant: sync spdk common for all providers (Karol Latecki) [11:12:45] Diff URL: https://github.com/spdk/spdk/compare/75327bc67e9a...a257328d69a9 [11:12:45] *** Parts: travis-ci (~travis-ci@ec2-54-166-130-32.compute-1.amazonaws.com) () [11:13:14] *** Joins: travis-ci (~travis-ci@ec2-54-80-149-10.compute-1.amazonaws.com) [11:13:15] (spdk/master) iSCSI: set a connection to EXISTING STATE in condition (Ziye Yang) [11:13:15] Diff URL: https://github.com/spdk/spdk/compare/a257328d69a9...1ba87aba31a8 [11:13:15] *** Parts: travis-ci (~travis-ci@ec2-54-80-149-10.compute-1.amazonaws.com) () [11:13:27] oh - I know the problem - it's more stuff with the shared map [11:13:43] i'm still not sure why I don't see this problem on my system though [11:14:59] *** Joins: travis-ci (~travis-ci@ec2-54-80-149-10.compute-1.amazonaws.com) [11:15:00] (spdk/master) test/iscsi: Add installation of socat in vm_setup.sh configuration (Pawel Niedzwiecki) [11:15:00] Diff URL: https://github.com/spdk/spdk/compare/1ba87aba31a8...341fff639718 [11:15:00] *** Parts: travis-ci (~travis-ci@ec2-54-80-149-10.compute-1.amazonaws.com) () [11:17:03] as a test, could you add "virt*;" to shared_lib/spdk.map? [11:17:08] lhodev: ^^^ [11:17:40] also "SPDK_LOG_*;" [11:22:33] jimharris: oh, yeah, right, re: symbol names in spdk.map. That is curious how yours works without it. I've located software collections updates for Oracle Linux that will enable me to install later versions of gcc/binutils. Doing that now. [11:22:50] Will try a build with those and as an independent test, alter the spdk.map. [11:37:31] jimharris: Without any addl changes on my part to spdk.map, the later versions of gcc/binutils failed to link as well which wasn't a surprise. So, I amended spdk.map with 'virt*' and 'SPDK_LOG_*'. Then, I had to add 'g_*'. This apparently got me through examples and app. [11:38:16] which g_ symbol was needed? [11:38:53] But, then failed in LINK test/app/histogram_perf/histogram_perf. libspdk_thread.so: undefined reference to spdk_log. That doesn't make sense because I have your patch that states to use static linking for all the tests. Dang it. [11:39:52] As for the g_symbol, that occurred during linking of nvmf_tgt. libspdk_app_rpc.so had undefined refs to g_subsystems_deps and g_subsystems. [11:41:02] I had reverted to my older compiler. Will try with the latest one I have. [11:43:50] With latest compiler, it fails to link at the same point as the older compiler. [11:58:30] lhodev: the static linking patch is only for unit tests - histogram_perf isn't a unit test [12:00:22] try adding "log" to test/app/histogram_perf/Makefile:42 [12:06:07] jimharris: via "make V=1", I can see the link line contains: "-lspdk_thread -lspdk_util" instead of being expanded to libspdk_thread.a and libspdk_util.a, respectively, hence the linker will by default attempt to use the shared libs versions of those. [12:06:21] *** Quits: waelhalbawi (a02259ed@gateway/web/freenode/ip.160.34.89.237) (Ping timeout: 252 seconds) [12:09:03] I just tried adding "log" as you described above, and that did link successfully as well as everything else. [12:15:34] for histogram_perf, that is expected [12:16:00] only tests under test/unit will explicitly link with the static libraries [12:16:29] because stuff under test/unit will mock up some function in the unit test - and that doesn't really jive with the shared library approach [12:16:42] bwalker: can you take a look at https://review.gerrithub.io/#/c/spdk/spdk/+/422394/? [12:21:25] jimharris: So, next steps? I'll amend https://review.gerrithub.io/#/c/spdk/spdk/+/422307/ removing the changes to mk/spdk.app.mk and mk/spdk.modules.mk. Those had added the push,pop,Bstatic stuff. [12:22:35] Then regarding my additional lines to shared_lib/spdk.map (virt*, SPDK_LOG*, g_*), shall I create a new patch for that, or did you want to amend one of yours? [12:23:27] Ditto for the addition of 'log' to test/app/histogram_perf/Makefile ? [12:23:50] do you know exactly which g_* are needed? I'd prefer not to add g_* to the map if we can avoid (assuming it's just a handful of globals we need to add) [12:24:19] then I can add those, plus the virt* and SPDK_LOG* to my patch [12:24:32] and i'll update my dependency patch with the log entry [12:24:42] I hammered "g_*" into there, so let me do a clean and re-build without it, then determine precisely only those that are needed. [12:24:55] thanks lhodev - i appreciate it [12:25:12] g_* was definitely the right thing to do to prove you could get it working :) [12:25:29] what about an rpath entry? i had one of those in my tree yesterday when i was playing around with it [12:29:54] What would you set the rpath to? spdk/build/lib? Does that enable it to resolve both to the source tree *and* would also resolve in the standard lib locations when installed? [12:32:51] Regarding the g_ symbols, I had to add: g_subsystems, g_subsystems_deps, g_spdk_iscsi_opts. [12:33:27] correct - but I need to test that to 100% confirm [12:35:59] i've updated my patches [12:38:50] jimharris: Have you, by chance, attempted this on FreeBSD ? [12:47:16] jimharris: I pushed my revised set, but I expect CI to fail owing to the dependency of yours going in first. [12:50:41] I guess I should've just waited for yours to merge. Doh! [12:51:03] i have not tried this on FreeBSD yet [12:53:56] Running out to grab a very late lunch. Be back in a bit. [13:09:21] jimharris: regarding errno, I misread that patch. errno is not set - the errno value is just returned [13:09:30] he should just be printing out 'rc' [13:09:54] and i don't think ibv_reg_mr gives you and kind of errno [13:10:03] like malloc [13:10:40] let me actually dig into this a bit more - the documentation on rdma mojo is not entirely clear [13:10:47] and that's usually more detailed than the man pages [13:11:04] it wasn't clear on any of them [13:11:14] I'll just pull up the code [13:11:46] even the code wasn't 100% clear - things like ibv_create_cq call into a function pointer and i lost interest in figuring out what the function pointer might be :) [13:12:01] the top layer is all just indirection to the real implementations [13:12:08] which are different for rxe, mlx5, mlx4, chlsio, etc. [13:17:37] aaaand it isn't consistent [13:17:41] some places set errno, some don't [13:22:53] shocker [13:24:16] sometimes I wonder how many applications actually ship, in production, using RDMA from user space [13:38:50] jimharris: I recall looking at a man page for ibv_reg_mr on one of our systems and it did state that it set errno on failure. [14:16:33] *** Joins: alekseymmm_ (050811aa@gateway/web/freenode/ip.5.8.17.170) [14:40:04] jimharris: I set my patch series passed both CI pools, and recalled that's 'cause the build of shared libs is disabled by default. [14:40:47] I also just noted that I had left the limitation in the configure script that prevents enabling shared libs on FreeBSD (though I had remembered to remove that from the CHANGELOG.md). [14:41:51] I'm trying to build with shared libs now on my FreeBSD VM, but it's failing while trying to build the DPDK, *sigh*. [15:22:48] Why do we have spdkcli and rpc.py ? they are both just cli , what is the difference ? [15:24:21] spdkcli is sort of like target-cli on linux [15:24:38] gives you a directory-tree-like structure that shows you what bdevs are configured [15:25:17] shell prompt where you can do things like 'ls' and 'help' [15:26:19] oh I see, more interactive ? [15:26:51] yes, interactive and user friendly [15:27:01] it's actually implemented by importing the code from rpc.py [15:27:11] so sending the same rpcs through the same path [15:28:18] thanks. If I write my own bdev and provide rpc.py functions then I have to write scomething in spdk_cli or it is configured automatically ? [15:28:44] it would need code added to spdkcli - but it's fairly easy to add [15:29:01] ok thanks for clarification [15:30:01] jimharris: resolved my FreeBSD VM installation issue, and was able to build with shared libs. [15:31:19] nice! [15:35:07] in bdev module functions there is a callback "write_config_json" . what is it for? who and when calls it ? [15:36:05] it's for generating json output that can be used to reload the same configuration if/when the app needs to be restarted [15:36:23] I think some of that is still in development, but the idea is that you can start the target, send it a bunch of rpc's to configure it [15:36:38] then send it a signal (SIGUSR?) [15:36:46] and it automatically writes out a json configuration file [15:36:52] if i have this json , how then I could restore bdev using it ? [15:37:03] then next time you load up the target, you can pass it the json configuration file [15:37:10] and it goes back to the state it was in when you dumped it out [15:37:40] the SIGUSR stuff is only plumbed in the iSCSI target, and it dumps legacy INI file format [15:37:58] but there are RPCs to tell the app "give me a json config dump of the current configuration" [15:38:22] like get_bdevs ? [15:39:08] ok what if I have the json config of my bdev, how could I use it to restore the bdev? [15:39:19] load_config RPC [15:39:27] is it rpc call or what ? [15:39:33] yes, RPC call [15:40:19] load _config is something general for all bdevs or specific for each one ? [15:41:17] for the whole app - all of the bdevs, iSCSI target nodes, NVMe-oF subsystems, vhost, etc. [15:41:49] reminder: community meeting in about 5.5 hours from now. There is a new link on http://www.spdk.io/community/ and the PW should be required this time (thanks Jim!) [15:41:51] there is also "save_config" [15:42:08] which gives you a configuration that you can pass to "load_config" later [15:42:09] ok. and this callback is called only on SIGUSR? [15:42:17] only iSCSI does the SIGUSR thing, sorry [15:42:23] or sigusr and save_config? [15:42:29] for everything else, you send the save_config RPC [15:42:33] to get a configuration [15:42:34] ok [15:42:35] as bwalker said, it's still under some development, so if you find any discrepencies, feel free to file a github issue [15:42:39] it makes sencse [15:43:04] thanks, I am going to test some of this calls [15:43:25] I don't think this is even documented yet [15:43:57] but on master they are both there in rpc.py [15:44:23] yeah - i don't see them in the jsonrpc documentation yet [15:44:53] this is why I have so many questions ) [15:46:07] I'm not sure if all of the correct hooks are implemented so that everything gets dumped out - it's definitely still in progress [15:46:18] although near the end at this point [15:47:29] could this json config load/store technique handle stacked bdevs ? like passthru on top of lvol on top of aio or others? [15:47:50] I mean does it check dependencies? [15:47:51] it should correctly handle that [15:47:55] ok nice [15:47:58] but please do report problems if you have any [15:47:58] Thank you [15:48:02] well - I'm not so sure actually [15:48:02] ok [15:48:07] i was just thinking about this [15:48:35] are you worried it gets the order wrong [15:48:50] i was - but i think it's right [15:49:01] it will spit it out in the same order the bdevs were originally registered [15:49:17] so minus that capacity expansion case we've talked about, it should be fine [15:49:54] ok it is still interesting for me to test [15:50:19] absolutely - more eyes on this would be great! [17:02:29] *** Quits: alekseymmm_ (050811aa@gateway/web/freenode/ip.5.8.17.170) (Quit: Page closed) [17:47:15] Is this a known, latent failure? https://ci.spdk.io/spdk/builds/review/5b18a06d0d2d96751dfcfcb603fb92c5defaf950.1534379335/ [18:02:08] *** Joins: lhodev_ (~lhodev@66-90-218-190.dyn.grandenetworks.net) [18:02:24] *** Quits: lhodev (~lhodev@inet-hqmc08-o.oracle.com) (Ping timeout: 256 seconds) [18:02:39] *** Parts: lhodev_ (~lhodev@66-90-218-190.dyn.grandenetworks.net) () [18:03:21] *** Joins: lhodev (~lhodev@66-90-218-190.dyn.grandenetworks.net) [19:37:33] *** Joins: waelhalbawi (6b03a57c@gateway/web/freenode/ip.107.3.165.124) [19:54:57] *** Quits: waelhalbawi (6b03a57c@gateway/web/freenode/ip.107.3.165.124) (Ping timeout: 252 seconds) [20:19:42] that's not one I've seen before but I don't see how it could be related to your patch [20:23:54] Right? Can we nudge it to re-run through the test pool? [20:29:03] i did :) [20:29:40] I even moved it to be beginning of the run queue for you. [20:31:01] You are awesome. [20:34:00] *** Joins: travis-ci (~travis-ci@ec2-54-92-220-203.compute-1.amazonaws.com) [20:34:01] (spdk/master) nvmf: Store thread in controller structure (Ben Walker) [20:34:02] Diff URL: https://github.com/spdk/spdk/compare/3113b446f126...008ec0bd914a [20:34:02] *** Parts: travis-ci (~travis-ci@ec2-54-92-220-203.compute-1.amazonaws.com) () [20:40:56] *** Joins: travis-ci (~travis-ci@ec2-54-226-101-102.compute-1.amazonaws.com) [20:40:57] (spdk/master) test/nvmf: add init and fini functions to tgt tests (Seth Howell) [20:40:57] Diff URL: https://github.com/spdk/spdk/compare/edfde53deffc...fdf5e5854b37 [20:40:57] *** Parts: travis-ci (~travis-ci@ec2-54-226-101-102.compute-1.amazonaws.com) () [20:45:08] bwalker: can you review this DPDK 18.08 patch series from darsto? [20:49:54] And..... it passed the 2nd time 'round. [20:55:50] FYI community meeting about to start, note that the letters in the PW are lower case, not upper case [20:57:42] peluse: ugh, I missed the upper v. lower when I set up the new meetings [20:58:00] no worries [20:58:18] I'll update the graphic tomorrow [20:58:28] a lot safer than update the meeting series, LOL [21:42:09] *** Joins: travis-ci (~travis-ci@ec2-54-226-101-102.compute-1.amazonaws.com) [21:42:10] (spdk/master) bdev/gpt: fail more gracefully on extended block size bdevs (Jim Harris) [21:42:10] Diff URL: https://github.com/spdk/spdk/compare/5b900148e58e...9ee494213087 [21:42:10] *** Parts: travis-ci (~travis-ci@ec2-54-226-101-102.compute-1.amazonaws.com) () [21:42:28] *** Joins: travis-ci (~travis-ci@ec2-54-226-101-102.compute-1.amazonaws.com) [21:42:29] (spdk/master) nvme: add spdk_nvme_ns_get_extended_sector_size (Jim Harris) [21:42:29] Diff URL: https://github.com/spdk/spdk/compare/fdf5e5854b37...5b900148e58e [21:42:29] *** Parts: travis-ci (~travis-ci@ec2-54-226-101-102.compute-1.amazonaws.com) ()