[00:11:09] *** Joins: tomzawadzki (~tomzawadz@192.55.54.44) [00:36:45] *** Joins: travis-ci (~travis-ci@ec2-54-161-181-102.compute-1.amazonaws.com) [00:36:46] (spdk/master) nvmf: Remove unused spdk_nvmf_handle_connect declaration (Ben Walker) [00:36:46] Diff URL: https://github.com/spdk/spdk/compare/45afbff73f51...9f2a0a67ae18 [00:36:46] *** Parts: travis-ci (~travis-ci@ec2-54-161-181-102.compute-1.amazonaws.com) () [00:49:32] *** Joins: ziyeyang_ (~ziyeyang@134.134.139.72) [00:50:46] *** Quits: ziyeyang (~ziyeyang@134.134.139.72) (Ping timeout: 264 seconds) [00:50:46] *** ziyeyang_ is now known as ziyeyang [01:00:05] *** Quits: tomzawadzki (~tomzawadz@192.55.54.44) (Ping timeout: 240 seconds) [01:00:41] *** Joins: tkulasek (~tkulasek@192.55.54.39) [01:02:31] *** Joins: tomzawadzki (~tomzawadz@134.134.139.74) [01:15:22] *** Quits: tomzawadzki (~tomzawadz@134.134.139.74) (Ping timeout: 264 seconds) [01:56:34] *** Joins: tomzawadzki (tomzawadzk@nat/intel/x-puulaxmoldmnqpjl) [01:57:22] *** Joins: tzawadzki (tomzawadzk@nat/intel/x-vkayjomvrykinutx) [01:57:22] *** Quits: tomzawadzki (tomzawadzk@nat/intel/x-puulaxmoldmnqpjl) (Remote host closed the connection) [02:17:35] *** Quits: gila (~gila@5ED74129.cm-7-8b.dynamic.ziggo.nl) (Read error: Connection reset by peer) [02:17:41] *** Joins: gila_ (~gila@5ED74129.cm-7-8b.dynamic.ziggo.nl) [02:21:19] *** Quits: gila_ (~gila@5ED74129.cm-7-8b.dynamic.ziggo.nl) (Read error: Connection reset by peer) [02:26:15] *** Joins: gila (~gila@5ED74129.cm-7-8b.dynamic.ziggo.nl) [04:32:58] *** Joins: dlw1 (~Thunderbi@114.255.44.139) [04:34:55] *** Quits: dlw (~Thunderbi@114.255.44.143) (Ping timeout: 260 seconds) [04:34:56] *** dlw1 is now known as dlw [05:43:45] *** Quits: dlw (~Thunderbi@114.255.44.139) (Ping timeout: 248 seconds) [07:04:36] ppelplin, tzawadzki please review quick fix: https://review.gerrithub.io/c/spdk/spdk/+/415254 (should take no more than 10 seconds :) ) [08:00:00] *** Joins: travis-ci (~travis-ci@ec2-54-161-181-102.compute-1.amazonaws.com) [08:00:01] (spdk/master) bdevperf: simplify bdevperf_submit_single (Jim Harris) [08:00:01] Diff URL: https://github.com/spdk/spdk/compare/9f2a0a67ae18...529d9b0dec31 [08:00:01] *** Parts: travis-ci (~travis-ci@ec2-54-161-181-102.compute-1.amazonaws.com) () [08:34:33] *** Quits: tzawadzki (tomzawadzk@nat/intel/x-vkayjomvrykinutx) (Ping timeout: 264 seconds) [09:27:08] that's pretty cool - Matias Bjorling is reviewing Jakub's OCSSD patches on GitHub [09:27:18] yay open source [09:27:34] he's actually reviewing on GerritHub I mean [09:28:39] *** Joins: travis-ci (~travis-ci@ec2-54-161-181-102.compute-1.amazonaws.com) [09:28:40] (spdk/master) test/nvmf: Use the real io_channel implementation (Ben Walker) [09:28:40] Diff URL: https://github.com/spdk/spdk/compare/529d9b0dec31...64d75fe2a616 [09:28:40] *** Parts: travis-ci (~travis-ci@ec2-54-161-181-102.compute-1.amazonaws.com) () [09:34:08] jimharris: I'm trying to remember how we excluded DPDK from scan-build, but I can't figure it out - can you refresh my memory? [09:34:13] or are we not actually excluding it? [09:35:12] looking... [09:37:02] does it get skipped by the way we invoke the DPDK make? [09:37:05] in dpdkbuild/Makefile? [09:40:37] not sure, doesn't look like anything special is going on there [09:41:09] the reason I ask is that intel-ipsec-mb fails with scan-build errors when I added it to the dpdkbuild makefile in a similar way [09:41:10] https://review.gerrithub.io/#/c/spdk/spdk/+/404983/ [09:42:48] and I find it hard to believe that DPDK has no scan-build warnings :) [09:48:22] *** Quits: tkulasek (~tkulasek@192.55.54.39) (Ping timeout: 264 seconds) [09:48:50] *** Joins: travis-ci (~travis-ci@ec2-54-161-181-102.compute-1.amazonaws.com) [09:48:51] (spdk/master) doc: use Doxygen subpages for top-level groupings (Jim Harris) [09:48:51] Diff URL: https://github.com/spdk/spdk/compare/64d75fe2a616...11d55d17f755 [09:48:51] *** Parts: travis-ci (~travis-ci@ec2-54-161-181-102.compute-1.amazonaws.com) () [09:53:25] yeah - that seems very doubtful [09:56:21] huh - when i run scan-build on my system, i get 41 errors on master [09:57:13] nothing in dpdk - but i really don't think scan-build ran against the dpdk build (but i need to disable their quiet mechanism to make sure) [09:58:07] 41 errors or 41 warnings [09:58:32] errors [09:58:43] i'm running scan-build 6.0 though [09:58:49] haven't looked at any of them yet [10:00:43] ubuntu doesn't call it scan-build, it calls it scan-build-6.0 (so autobuild.sh won't use it by default) [10:01:16] yeah - somehow the DPDK build system is dropping the scan-build [10:01:42] i guess we'll call that a feature of the dpdk build system :) [10:10:41] we could carry our own fork of intel-ipsec-mb and fix the issues (they are all just dead stores that seem safe to remove) [10:10:45] but I don't really want to do that if we can avoid it [10:12:51] I wonder if DPDK overrides CC somewhere - I think that's how scan-build inserts itself into the build process [10:16:39] I see 42 errors on master with clang 6.0 scan-build as well [10:16:44] looks like almost all of them are in unit test code [11:06:00] drv: can you add your +2 again to https://review.gerrithub.io/#/c/spdk/spdk/+/414951/? [11:06:42] ok, added [11:07:09] I don't totally comprehend the design of the spdkcli stuff - I'm just trusting that Karol has it right :) [11:09:53] have you used it at all? i've been testing his changes locally [11:11:14] these ui_command_* member functions correspond exactly to commands you can run from the spdkcli command line - but where they are defined determines where in the spdkcli tree hierarchy you can call them [11:12:40] for example, UILvolStores has a ui_command_create and ui_command_delete function for creating and deleting logical volumes - since it's in the UILvolStores class, it can only be called if your "pwd" is in the /bdevs/Logical_Volume hierarchy [11:16:44] *** Joins: travis-ci (~travis-ci@ec2-54-158-228-19.compute-1.amazonaws.com) [11:16:44] (spdk/master) scripts/rpc.py: pass named args to vhost.py (Karol Latecki) [11:16:45] Diff URL: https://github.com/spdk/spdk/compare/5cd1b16a5015...25c11b8e25a6 [11:16:45] *** Parts: travis-ci (~travis-ci@ec2-54-158-228-19.compute-1.amazonaws.com) () [11:20:04] I tried it briefly when we first merged it [11:22:01] is NVME_QUIRK_OCSSD needed if we're adding this new ocssd_supported function? [11:22:44] this new function basically is saying that just looking at the QUIRK is not enough [11:22:46] that's what uses the quirk [11:23:14] right, the current implementation (that cnexlabs device) sets a particular value in the vendor-specific data to indicate that Open Channel command set is supported [11:23:18] it doesn't only look at the quirk though - it also compare the vid [11:23:39] yeah, right now it doesn't matter since that's the only device with the quirk, but in theory other devices could have different vendor-specific behavior [11:23:40] and comparing the vid here is duplicating what the quirk was for [11:23:51] I guess we could have different quirks per vendor instead [11:24:04] it's all pretty hypothetical while there's only one device [11:24:12] i guess i think of a quirk as a definitive thing [11:24:27] meaning if NVME_QUIRK_OCSSD is set then this device supports OCSSD [11:24:44] I'm not sure if it's possible to configure qemu with a device that has that vendor:device ID but does not support OCSSD [11:24:52] but if it is, then we should be checking the VS thing [11:24:59] (otherwise we could just use the quirk) [11:25:57] we could just remove the quirk and use the vendor ID + VS check, I guess [11:26:39] assuming all devices from that vendor report the vendor-specific data in that format [11:26:41] i guess it's fine for now - all of this is open to reinterpretation and reimplementation as the spec evolves [11:26:58] yeah, we will definitely have to revisit it once we have more devices/new specs [11:27:10] the quirk is internal to the nvme lib, so it's not exposed in the public API or anything [11:27:16] so I don't think it should be a big deal to change that later [11:27:51] i think a ctrlr->flag is more appropriate [11:27:57] similar to SPDK_NVME_CTRLR_SGL_SUPPORTED [11:28:24] hey do you guys ever get this (below) when running an app under gdb but not get any kinda of errors when not running under gdb? [11:28:25] ==70362==LeakSanitizer has encountered a fatal error. [11:28:25] ==70362==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1 [11:28:25] ==70362==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc) [11:29:07] git rid of the quirk, call this new ocssd_supported function and if it returns true do ctrlr->flags |= SPDK_NVME_CTRLR_OCSSD_SUPPORTED [11:29:21] the ctrlr flags aren't reported in public API either, currently [11:29:37] this ocssd_supported thing is meant to be for the NVMe lib user [11:30:07] true - so this new function just returns if the ctrlr->flag is set or not - a separate internal function does all of this vid and vs checking [11:30:13] that would be ok [11:39:23] I think the direction it's going is that OCSSD will be detected as a new command set, which we have a public API for [11:39:51] and this quirk will determine if support for the command set will be reported even if the device doesn't actually report it in the registers [11:41:55] but it's going to be a long time probably until an NVMe SSD supports OCSSD through a new command set [11:42:05] yeah I think so [11:42:33] quirks today are solely based on device/vendor ID - this OCSSD determination stuff doesn't really fit into that [11:42:38] peluse: ASAN just messes up when running with gdb. You can ignore that [12:02:04] *** Quits: pohly (~pohly@p54BD5098.dip0.t-ipconnect.de) (Quit: Leaving.) [12:34:31] peluse: I think I have the intel-ipsec-mb build working now, if you want to rebase your patch on that: https://review.gerrithub.io/#/c/spdk/spdk/+/404983/ [13:34:22] bwalker, thanks [13:34:42] drv, cool. yeah I just got LBA as IV working and have a few more things to clean up then I'll give it a whirl [14:05:41] drv, how do I get "git submodule" to pick up the 2nd submodule? All the commands I try seem to only update / affect dpdk (like a simple "git submodule"? [14:06:36] git submodule update --init should get them all [14:09:11] shit [14:09:28] OK, give me a few... [14:24:14] got it, building now [14:26:56] the submodule UI is pretty clunky [14:32:01] yeah, there are some other issues that we need to look at with that patch but first I can't build after rbease w/master. What happened to spdk_internal/bdev.h? [14:32:23] it's now spdk/bdev_module.h [14:32:29] shouldn't require any other changes, I believe [14:33:38] OK [14:34:15] K [14:35:16] forgot to mention, I need CONFIG_RTE_LIBRTE_KVARGS=y as well. I'll add it to the Makefile and let you know what doesn't work next :) [14:35:20] *** Joins: travis-ci (~travis-ci@ec2-54-161-181-102.compute-1.amazonaws.com) [14:35:21] (spdk/master) bdev/rbd: destroy ioctx in bdev_rbd_init (Jim Harris) [14:35:22] Diff URL: https://github.com/spdk/spdk/compare/25c11b8e25a6...f22755cfad1e [14:35:22] *** Parts: travis-ci (~travis-ci@ec2-54-161-181-102.compute-1.amazonaws.com) () [14:36:04] peluse: yeah, I had to add that in the intel-ipsec-mb patch to get it to build [14:36:11] should already be taken care of if you rebase on that [14:36:19] yeah, I see you had that in there. OK so here's the issue [14:36:30] one sec [14:53:36] great, now I can build "the old way" :) I'm getting an ld error on LINK test/unit/lib/iscsi/iscsi.c/iscsi_ut. Have to go to the vet soon so will just wait and see how your (drv) poking into what's up with your patch goes... keep me posted and thanks!! [14:53:50] can-->can't [14:54:32] I could have sworn this was building the extra DPDK libs after adding them via dpdkbuild/Makefile, but now I can't reproduce that [14:54:49] I must have broken it somewhere along the line; still investigating [14:58:52] drv, I probably did it through some sort of telekinesis... [15:03:33] I wonder if I just had local modifications to the dpdk config and forgot about it [15:03:54] it works if I comment out the KVARGS, CRYPTODEV, and REORDER lines in dpdk/config/common_spdk [15:04:16] (well, works more, still not quite happy finding the right spot for the IPsec lib) [15:05:42] haha, "works more". story of my life [15:07:44] if we don't mind requiring the intel-ipsec-mb library, we could just check those config changes into our dpdk submodule [15:07:52] but I'm open to arguments for or against :) [15:11:07] it's pretty small... doesn't seem like a big deal but that kind of thinking can lead a bunch of small things that end up taking a lot of time eventually. Gotta run, be back in an hour or so.... [15:12:14] the main argument I would pose is that it won't work on non-x86 platforms [15:12:31] (I assume - I haven't checked, but it seems like the intel-ipsec-mb lib doesn't have fallback C code for the assembly) [16:12:25] *** Joins: travis-ci (~travis-ci@ec2-54-161-181-102.compute-1.amazonaws.com) [16:12:26] (spdk/master) ocssd: check whether ctrlr support ocssd (Xiaodong Liu) [16:12:26] Diff URL: https://github.com/spdk/spdk/compare/f22755cfad1e...5fc12ae9e284 [16:12:26] *** Parts: travis-ci (~travis-ci@ec2-54-161-181-102.compute-1.amazonaws.com) () [16:15:06] peluse: this patch should allow you to get rid of the manual copying of libcrypto.a at least: https://review.gerrithub.io/#/c/spdk/spdk/+/415351/ [16:15:18] (still no solution for the intel-ipsec-mb thing, gotta think over the options some more) [16:16:08] you should be able to drop 'crypto' from the DPDK_LIB_LIST in env.mk once that's in [16:48:44] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [17:12:26] I have not investigated the code with step by step yet. [17:12:50] May I do that or do you have any good idea? Vishal is already working on that? [17:15:10] Honestly I had waited for your feedback but I try to do with you if better. [17:37:50] Hi Shuhei [17:37:51] *** Joins: travis-ci (~travis-ci@ec2-54-158-228-19.compute-1.amazonaws.com) [17:37:52] (spdk/master) blobstore: check return code in IO freeze completion (Maciej Szwed) [17:37:53] Diff URL: https://github.com/spdk/spdk/compare/5fc12ae9e284...980ebc979049 [17:37:53] *** Parts: travis-ci (~travis-ci@ec2-54-158-228-19.compute-1.amazonaws.com) () [17:38:32] I was ready to take off soon. Are you trying something with the patch right now? [17:40:25] No I don't. [17:41:12] yeah the QoS failure I wasn't sure about as to why it failed with my latest changes [17:42:00] My feedback is only on paper. please put update on Gerrit. I'll check it. Thank you. [17:42:28] thinking to try test/iscsi_tgt/qos/qos/sh locally on my system as well [17:42:51] test/iscsi_tgt/qos/qos.sh* [17:43:19] I feel reasonable [18:25:39] *** Joins: ning (~user@58.247.53.202) [18:36:05] *** Joins: dlw (~Thunderbi@114.255.44.143) [18:56:41] *** Quits: ning (~user@58.247.53.202) (Ping timeout: 276 seconds) [18:57:52] *** Joins: ning (~user@58.247.53.202) [19:32:53] exit [20:36:04] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Ping timeout: 260 seconds) [20:50:32] *** Joins: pohly (~pohly@p54BD5098.dip0.t-ipconnect.de) [20:56:41] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [21:39:23] *** Quits: ning (~user@58.247.53.202) (Ping timeout: 265 seconds) [21:53:41] *** Quits: dlw (~Thunderbi@114.255.44.143) (Remote host closed the connection) [21:53:57] *** Joins: dlw (~Thunderbi@114.255.44.143) [22:11:08] *** Joins: ning (~user@58.247.53.202) [22:18:02] *** Quits: ning (~user@58.247.53.202) (Read error: Connection reset by peer) [22:18:19] *** Joins: ning (~user@58.247.53.202) [22:32:09] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Ping timeout: 260 seconds) [22:40:04] *** Quits: ning (~user@58.247.53.202) (Ping timeout: 268 seconds)