[01:18:23] *** Quits: Param (~Param@106.201.127.150) (Quit: Param) [01:29:49] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Ping timeout: 260 seconds) [03:52:22] *** Quits: tomzawadzki (tomzawadzk@nat/intel/x-qbdbeorqtxintiiw) (Remote host closed the connection) [03:52:32] *** Joins: tomzawadzki (~tomzawadz@192.55.54.42) [03:57:14] *** Joins: lhodev1 (~Adium@inet-hqmc05-o.oracle.com) [03:57:16] *** Joins: gila_ (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [03:59:11] *** Quits: lhodev (~Adium@inet-hqmc05-o.oracle.com) (Ping timeout: 264 seconds) [03:59:11] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Ping timeout: 264 seconds) [04:28:45] *** Joins: peluse- (peluse@nat/intel/x-oiydeqqhjgjcplpg) [04:29:11] *** Joins: mszwed_ (mszwed@nat/intel/x-khjpqpcklzkgfept) [04:31:46] *** Joins: tsg_ (tsg@nat/intel/x-rhicmdibrwqmcyrj) [04:34:26] *** Quits: peluse (~peluse@192.55.54.41) (Ping timeout: 264 seconds) [04:34:27] *** Quits: mszwed (~mszwed@192.55.54.41) (Ping timeout: 264 seconds) [04:34:27] *** peluse- is now known as peluse [04:34:27] *** Quits: tsg (tsg@nat/intel/x-ctidzckhkjvtmwto) (Ping timeout: 264 seconds) [04:34:28] *** tsg_ is now known as tsg [04:34:28] *** mszwed_ is now known as mszwed [05:36:59] *** Joins: Param (~Param@157.49.19.195) [05:50:35] *** Joins: tzawadzki (~tomzawadz@192.55.54.42) [05:53:59] *** Quits: tomzawadzki (~tomzawadz@192.55.54.42) (Ping timeout: 255 seconds) [06:46:20] *** Quits: ppelplin (~ppelplin@192.55.54.41) (Ping timeout: 255 seconds) [06:46:41] *** Joins: ppelplin (ppelplin@nat/intel/x-vgcurtdsrvbzzqsa) [06:48:53] *** Quits: tsg (tsg@nat/intel/x-rhicmdibrwqmcyrj) (Ping timeout: 240 seconds) [06:49:03] *** Joins: tsg (tsg@nat/intel/x-zsfrvqvejamlilok) [07:45:08] *** Quits: lhodev1 (~Adium@inet-hqmc05-o.oracle.com) (Remote host closed the connection) [07:48:47] *** ChanServ sets mode: +o peluse [08:02:18] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [08:05:03] *** Joins: lhodev (~Adium@66-90-218-190.dyn.grandenetworks.net) [08:12:56] *** Joins: Isaac_ (68320710@gateway/web/freenode/ip.104.50.7.16) [08:13:22] *** Quits: Isaac_ (68320710@gateway/web/freenode/ip.104.50.7.16) (Client Quit) [08:14:04] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Ping timeout: 260 seconds) [08:21:05] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [08:23:41] Hi All, I looked into implementation of Command Supported and Effects in NVMe0F. So this is my inference there should be the effects data structure returned for the Admin Commands (0-255) and IO Commands (0-255). So first I will start looking into which are all the possible commands that can change the Effects Data structure in the following Admin and IO commands and will proceed from there.. [08:24:09] Any suggestions [08:27:12] *** Joins: Isaac_ (68320710@gateway/web/freenode/ip.104.50.7.16) [08:27:25] Reminder: Community meeting in 30 min from now. Info at http://www.spdk.io/community/ [08:49:04] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Ping timeout: 260 seconds) [08:54:27] jimharris, which one of these crypto drivers should we start with? http://dpdk.org/doc/guides-16.04/cryptodevs/index.html [08:58:10] it's ok to just start with the software driver and the aes-cbc algorithms [08:58:15] but you may want to start here: http://dpdk.org/doc/guides-16.04/prog_guide/cryptodev_lib.html [08:58:34] thx [08:58:38] this is the generic API that SPDK should program against - the details of the crypto drivers themselves are abstracted behind that [08:59:21] community meeting now [09:07:02] *** Joins: johnmeneghini (~johnmeneg@pool-96-252-112-122.bstnma.fios.verizon.net) [09:08:00] *** Quits: gila_ (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Ping timeout: 268 seconds) [09:22:55] *** Quits: Isaac_ (68320710@gateway/web/freenode/ip.104.50.7.16) (Ping timeout: 260 seconds) [09:55:37] *** Quits: johnmeneghini (~johnmeneg@pool-96-252-112-122.bstnma.fios.verizon.net) (Quit: Leaving.) [10:29:42] jimharris: the NVMe-oF RPC methods for managing hosts are ready for your review, if you get a free moment: https://review.gerrithub.io/#/c/396063/ [10:36:57] *** Quits: tzawadzki (~tomzawadz@192.55.54.42) (Ping timeout: 256 seconds) [10:56:17] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [12:03:04] *** Quits: Param (~Param@157.49.19.195) (Quit: Param) [12:04:19] *** Joins: sethhowe (~sethhowe@134.134.139.75) [12:40:37] *** Quits: sethhowe (~sethhowe@134.134.139.75) (Remote host closed the connection) [12:43:58] *** Joins: sethhowe (sethhowe@nat/intel/x-jspryxnujviuojhp) [13:38:48] drv: looking at https://review.gerrithub.io/#/c/396063/15/app/nvmf_tgt/nvmf_rpc.c [13:39:27] is there any way to get the rpc string name itself (i.e. "nvmf_subsystem_add_host") in the registered rpc routine? [13:39:39] not currently [13:39:43] looks like those three functions are exactly the same except for ctx->op [13:40:20] maybe you could make a common function then that each of those three routines could call? [13:40:23] yeah, I was considering refactoring it some more to eliminate duplication [13:40:34] but it got a little bit out of hand and I didn't want to make it harder to follow [13:41:08] I guess the final code I ended up with wouldn't be that hard to refactor that way, actually [13:41:12] oh - it is a bit different [13:41:23] the json object passed is different for allow_any_host [13:41:31] the parameters are different for that one, yeah [13:42:21] it could probably still be refactored to pass the decoders to the common function [13:42:50] could we use ANY/!ANY like we do for iSCSI [13:43:02] I wanted to avoid magic strings like that [13:43:05] and nix allow_any_host [13:43:15] this also matches the naming that the kernel NVMe-oF sysfs configuration uses [13:43:25] (a separate allow_any_host flag) [13:43:51] so then should we change iSCSI to have a similar allow_any_host operation? [13:44:07] not as part of this patch of course :) [13:46:00] i'm fine with the allow_any_host - I think a common function that maybe just takes the ctx->op and the decode_object parameters would probably reduce 100+ lines of code [13:46:06] but we can refactor that later [13:47:53] sure, I am OK with moving iSCSI to this model too - I'd generally prefer that over the magic strings [13:48:10] but I'll leave that up to the iSCSI maintainers :) [13:48:53] and I can do another patch that refactors this to reduce code duplication - the same pattern will apply to the add_ns/remove_ns and add_listener/remove_listener calls once those are in place as well [14:14:34] lol [14:14:38] can you take a look at https://review.gerrithub.io/#/c/392144/ [14:16:21] looks good, just merged it [14:22:32] *** Quits: sethhowe (sethhowe@nat/intel/x-jspryxnujviuojhp) (Remote host closed the connection) [14:26:30] *** Joins: sethhowe (~sethhowe@134.134.139.75) [16:50:09] trying to get our dpdk to build a crypto PMD and per the docs I need to "Set CONFIG_RTE_LIBRTE_PMD_AESNI_MB=y in config/common_base." but not quite sure how to do that with what have in the spdk repo... any suggestions? (I've tried a few things, can't seem to get it included) [16:50:34] looking... [16:51:56] our dpdk config is checked into the DPDK submodule - you could just patch your submodule directly to get started [16:52:21] yeah, just not sure what to change or where [16:52:42] config/common base and rebuild didn't seem to include the crypto stuff [16:53:07] the spdk-specific config is in config/common_spdk [16:53:13] cool [16:53:21] do you know if the crypto stuff is in the DPDK version we have? [16:54:20] I guess it does have that config flag at least, so it should be ok [16:56:15] the docs call for a different flag for the virtual PMD, the one I mention above, I added it but doesn't look like its getting picked up [16:56:41] maybe I need both [16:57:31] i think you'll need CONFIG_RTE_LIBRTE_CRYPTODEV=y too [16:57:41] what kind of problem are you seeing - is it just not building at all, or it builds but isn't linked into our apps? [16:58:14] we set that one to N explicitly in common_spdk [16:58:22] I changed it to y [16:59:13] and the driver seems to exist but when I try to add the init command I get unfeined reference to rte_eal_vdev_init() which I'm just assuming is because I'm not getting that driver built/linked in correctly [16:59:49] oh wait, that function doesn't seem to be in our dpdk [17:00:48] can you start with just calling rte_cryptodev_count()? [17:01:18] get that to link first, and then have it return something greater than 0 [17:01:21] I guess, I'm just following the directions :) [17:01:41] specifically which directions are you following? just want to follow along :) [17:02:10] http://dpdk.org/doc/guides-16.04/cryptodevs/aesni_mb.html section 2.4 [17:03:41] hmmm, I grabbed the latest full DPDK and rte_eal_vdev_init() only exists in a doc?? [17:03:50] can you try a newer guide? [17:03:51] http://dpdk.org/doc/guides-17.11/cryptodevs/aesni_mb.html [17:03:57] 16.04 is almost 2 years old [17:04:25] that function is now called rte_vdev_init() [17:04:46] yeah I just saw that [17:04:48] On Sunday 04 December 2016 02:25 AM, Jerin Jacob wrote: [17:04:48] rte_eal_dev_init() is a misleading name. [17:04:48] It actually performs the driver->probe for vdev, [17:04:48] which is parallel to rte_eal_pci_probe. [17:04:48] Changed to rte_eal_vdev_probe for consistency and [17:04:49] moved the vdev specific probe to eal_common_vdev.c [17:05:25] where'd you find that? [17:05:33] oh, wait [17:05:37] you'll need to add the crypto libs to DPDK_LIB_LIST in lib/env_dpdk/env.mk so they actually get linked into our apps [17:05:51] i just changed the version number in the URL [17:06:22] ugh [17:06:30] drv, OK thanks [17:06:54] probably with one of these wildcard checks around it if they were introduced recently [17:07:22] (we're probably broken with older DPDK now anyway, but it would be nice to avoid unnecessarily breaking compat) [17:08:02] jimharris: LTO got busted again (maybe with the unit test mk refactor stuff), this seems to get it back to working again: https://review.gerrithub.io/#/c/401074/ [17:08:14] we should add a VM to the test pool that enables LTO [17:08:44] lgtm [17:10:13] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [18:21:28] *** Quits: sethhowe (~sethhowe@134.134.139.75) (Remote host closed the connection) [18:22:59] *** Joins: sethhowe (sethhowe@nat/intel/x-aszulhnoxrifhqjv) [18:31:24] *** Quits: sethhowe (sethhowe@nat/intel/x-aszulhnoxrifhqjv) (Remote host closed the connection) [18:34:14] *** Joins: sethhowe (sethhowe@nat/intel/x-gzrjnmobpivphihb) [19:13:30] *** Joins: Param (~Param@157.49.36.100) [19:58:31] *** Quits: Param (~Param@157.49.36.100) (Ping timeout: 256 seconds) [22:33:07] *** Joins: ziyeyang_ (ziyeyang@nat/intel/x-vceweeeahpeilejd) [23:04:37] *** Joins: tomzawadzki (~tomzawadz@192.55.54.42) [23:17:56] *** Quits: ziyeyang_ (ziyeyang@nat/intel/x-vceweeeahpeilejd) (Quit: Leaving) [23:20:52] *** Quits: tomzawadzki (~tomzawadz@192.55.54.42) (Remote host closed the connection)