[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)