[00:28:37] *** Quits: lhodev (~lhodev@66-90-218-190.dyn.grandenetworks.net) (Ping timeout: 256 seconds) [00:37:38] *** Joins: lhodev (~lhodev@66-90-218-190.dyn.grandenetworks.net) [00:39:45] *** Joins: tkulasek (~tkulasek@134.134.139.75) [03:45:47] *** Quits: dlw (~Thunderbi@114.255.44.143) (Ping timeout: 244 seconds) [03:49:00] *** Quits: tomzawadzki (~tomzawadz@134.134.139.72) (Remote host closed the connection) [03:52:30] *** Joins: tomzawadzki (tomzawadzk@nat/intel/x-zqswzcunyicwuspe) [05:05:00] *** Joins: lyan (~lyan@2605:a000:160e:2124:4a4d:7eff:fef2:eea3) [05:05:24] *** lyan is now known as Guest92142 [05:22:32] drv, jimharris please take a quick look at my follow-up on when you get a chance... https://review.gerrithub.io/c/spdk/spdk/+/418549 [05:58:05] *** Joins: johnmeneghini (~johnmeneg@pool-100-0-53-181.bstnma.fios.verizon.net) [07:09:36] jimharris, drv or bwalker: how does the hotplug should behave when it is enabled but there is no TransportID entry in [Nvme] section? [07:10:34] currently it will grab all NVMe devices and add them as HotInNvme... [07:20:34] as for https://review.gerrithub.io/#/c/spdk/spdk/+/417962/ - are we developing NVMe-over-JSON-RPC ;) Is there something behind this patch I can't see? [07:21:03] *** Joins: philipp-sk (~Philipp@ktnron0916w-lp130-02-76-66-162-159.dsl.bell.ca) [07:38:46] *** Quits: tomzawadzki (tomzawadzk@nat/intel/x-zqswzcunyicwuspe) (Ping timeout: 264 seconds) [07:52:02] pwodkowx - the HotInNvme behavior is correct - but I think it needs to be changed somewhat [07:52:40] the HotplugEnable config flag currently covers both hot remove and hot insert [07:52:51] but i think it needs to be separated [07:53:32] because i think the most common use case will be to detect hot remove, but don't automatically attach on hot insert [07:53:42] It will block moving HotplugEnable to RPC -> https://review.gerrithub.io/#/c/spdk/spdk/+/418723/ [07:54:27] all our tests will fail if HotpluEnable is On :( [07:54:39] on 417962 - yes, we are doing NVMe-over-JSON-RPC - it's part of enabling management/configuration/test tools to interact with SPDK-attached NVMe devices [07:54:57] brb, need to reboot [08:00:55] *** Quits: sethhowe_ (sethhowe@nat/intel/x-uvvumoidkzsvgjvr) (Remote host closed the connection) [08:05:50] jimharris, i don't have permissions to fork a repo to the spdk github project. Can I send you the details to do it? (its for the ipsec library, we need a tiny tweak to the makefile for us to use it with crypto) [08:06:15] jimharris: as for Hotplug, maybe add some separate RPC just to enable or disable this at runtime [08:07:12] pwodkowx: agreed [08:08:14] this HotInNvmeX seems fragile though - what happens when user hot inserts an SSD, and HotInNvme0 name is used [08:08:20] user saves config, then reloads [08:08:51] another SSD is hot inserted, it will try to use HotInNvme0 again since the g_hot_insert_nvme_controller_index was reset since the application restarted [08:13:43] This is not only nvme hotplug issue. If you create Malloc bdev with forced name 'Malloc0' and another one automatic name this will faile in the same way. I think there are more bdev types that are broken in the same way. [08:13:57] peluse: sure - give me the github url for the ipsec library and i'll set up the fork [08:14:28] gracias [08:14:43] then i think you should be able to create an spdk branch in the repo (based off of whatever ipsec release tag) and add your makefile patch [08:15:09] https://github.com/intel/intel-ipsec-mb and I guess you just fork the repo and I pick the specific version when I submit the patch with the submodule right? [08:15:14] pwodkowx: good point [08:15:27] LOL, yeah [08:15:32] peluse: sort of [08:15:46] the submodule will point to the specific commit [08:16:00] yeah, that's what I mean. I have the commit ID that I need [08:16:02] but you'll still need the spdk branch i think [08:16:07] yep [08:16:07] OK [08:17:16] and hard for me to believe but with drv's crash course in Makefile crap, I have all this shit working so things build w/crypto correctly by using --with-crypto and everything builds fine w/o it by not specifying it. Will submit it all today [08:18:21] https://github.com/spdk/intel-ipsec-mb [08:20:53] pwodkowx: maybe we should make the malloc rpc require the name parameter? [08:21:48] or we make all of these modules learn how to pick an unused name [08:21:57] maybe all rpc should require a name [08:24:03] jimharris, thanks [08:26:35] btw when making rpc doc for bdevs I saw that this RPC API could be standarized. most common example is that some RPC take "name" and some of them "bdev_name" when constructing bdev. Not mentioning that some of them have the name parameter required and some optional. [08:27:33] *** Joins: sethhowe (~sethhowe@192.55.54.39) [08:27:49] ugh [08:42:49] jimharris, sorry to bug... is there another step to get the new forked repo hooked into gerrithub? [08:45:42] *** Joins: peter_turschm (~peter_tur@66.193.132.66) [08:49:02] yes - there was - can you try it again? [08:49:06] sorry - my first time doing this [08:50:01] no worries [08:50:16] closer :) [08:50:18] one sec [08:52:14] I'm guessing you might have to make the branch? [08:52:34] "To https://review.gerrithub.io/spdk/intel-ipsec-mb [08:52:34] ! [remote rejected] HEAD -> refs/for/spdk (branch spdk not found) [08:52:34] error: failed to push some refs to 'https://review.gerrithub.io/spdk/intel-ipsec-mb' [08:52:34] " [08:53:14] possibly [08:53:46] coo, I figured just "spdk" as this shouldn't change with versions I don't think [08:53:54] yeah - spdk is fine [08:53:58] we can change it later [08:54:10] what exactly did you try to push? [08:54:25] your patch? or just the spdk branch tag? [08:56:06] which tag do you want to base spdk off of - v0.50? [08:56:43] the tag we need is... wait for it :) [08:57:03] well, the commit is d88e6fde102c5fea622247b3441ad07988aae980 which is version 48 [08:57:26] I created a local branch called SPDK and tried to push to this: [08:57:49] [remote "review"] [08:57:49] url = https://review.gerrithub.io/spdk/intel-ipsec-mb [08:57:49] push = HEAD:refs/for/spdk [08:58:16] and on my local branch I checkout out that commit and make the Makefile change we need [08:59:59] i think you have to push the spdk branch directly first [09:00:13] but i don't think you have privileges to create branches that don't start with dev/ [09:00:47] ok - can you git fetch your repo again? [09:00:55] and checkout the spdk branch i just created [09:00:57] then it should work [09:02:42] will do [09:04:40] so I see the spdk branch, is that already based off the commit above so all I need to do is checkout that branch, make my one change and then push? [09:06:35] jimharris, peluse: you can create the branch on GerritHub via the Projects > Branches menu (or if you already created it, make sure to push back to GerritHub to sync it) [09:06:59] just pushed so let's see what happens :) [09:07:07] also make sure the rights are set up correctly for spdk/intel-ipsec-mb - you'll want to add the SPDK Maintainers group in place of whatever user imported it to GerritHub [09:08:52] drv, after that lands, I'll update your patch with all the needed changes and the new submodule repo and commit and we should be ready to rock and roll! [09:08:59] sweet [09:09:50] DAMNIT, I spelled CFLAGS "CLAGS". Good lord [09:10:32] (fixed) [10:30:00] *** Quits: peter_turschm (~peter_tur@66.193.132.66) (Remote host closed the connection) [10:42:02] *** Joins: peter_turschm (~peter_tur@66.193.132.66) [11:01:05] bwalker, jimharris - one liner dependency for the only other build system related patch for crypto when you guys get a chance: https://review.gerrithub.io/c/spdk/intel-ipsec-mb/+/419004 [11:02:34] done - bwalker, go ahead and push it once you've looked [11:03:33] gracias [11:55:39] *** Quits: tkulasek (~tkulasek@134.134.139.75) (Ping timeout: 260 seconds) [13:15:19] jimharris: reminder - I still need permission to push the above review [13:34:09] peluse: ipsec patch is merged [13:47:13] *** Joins: sethhowe_ (sethhowe@nat/intel/x-mikigcdopynqthkr) [13:49:27] *** Quits: sethhowe (~sethhowe@192.55.54.39) (Ping timeout: 240 seconds) [13:58:00] *** Joins: alekseymmm (bcf3adf1@gateway/web/freenode/ip.188.243.173.241) [14:18:36] *** Quits: alekseymmm (bcf3adf1@gateway/web/freenode/ip.188.243.173.241) (Quit: Page closed) [14:26:18] I think I'm finally catching up on my backlog here [14:43:50] *** Quits: Guest92142 (~lyan@2605:a000:160e:2124:4a4d:7eff:fef2:eea3) (Remote host closed the connection) [16:09:49] muchas gracias [16:10:58] I'll update drv's patch now and push it. After that I think the only other dependency is the mock of dma free that I had initially agreed I didn't need but then after testing realized asan didn't think freeing something that was never alloc'd [17:28:15] *** Quits: peter_turschm (~peter_tur@66.193.132.66) (Remote host closed the connection) [17:30:14] hmmm... anyone know where the file dpdk/config/common_spdk comes from? It exists in the spdk repo but I don't see it in our dpdk fork. Generated somewhere that I don't see? Right in front of my face probably :) [17:30:54] you mean our dpdk fork on github.com? [17:31:04] yeah, I don't see it there [17:31:21] did you change branch from master to spdk-18.05? [17:31:23] wait, maybe I'm not looking on the right branch [17:31:25] haha [17:41:30] BTW, drv had asked me to base these crypto related dpdk patches on 18.02, not 18.05. Can address that obviously pretty easily but that's why they are all 18.02 branch based [18:21:00] bwalker, so at least one of my questions on the mailing list is now clear by looking at the code but would probably be good to provide some brief answers anyway.... thanks! [18:27:34] peluse: can you look at https://review.gerrithub.io/#/c/spdk/spdk/+/406977/? [18:27:51] i love how the zcopy stuff turned out [18:32:39] ya, just looked at the one Ben mentioned in the email. [18:38:38] OK, I dropped the ball on keeping up with that one.. there's added complexity since patch set 5 (when I last paid attention) and I'm leaning towards your initial position now, will comment now [18:39:14] *** Joins: dlw (~Thunderbi@114.255.44.143) [20:06:28] *** Quits: guerby (~guerby@april/board/guerby) (Ping timeout: 256 seconds) [20:09:01] *** Joins: guerby (~guerby@ip165.tetaneutral.net) [20:09:01] *** Quits: guerby (~guerby@ip165.tetaneutral.net) (Changing host) [20:09:01] *** Joins: guerby (~guerby@april/board/guerby) [20:59:07] *** Quits: philipp-sk (~Philipp@ktnron0916w-lp130-02-76-66-162-159.dsl.bell.ca) (Ping timeout: 244 seconds) [21:27:15] *** Joins: bwalker_ (~bwalker@ip70-190-226-244.ph.ph.cox.net) [21:27:15] *** ChanServ sets mode: +o bwalker_ [21:27:48] meeting link says it is cancelled - am I clicking the wrong one? [21:30:20] checking... [21:30:37] i just joined but using a link from the meeting invite that anna sent out to intel folks [21:30:44] ah ok [21:30:49] can you paste it? [21:31:09] https://intel.webex.com/intel/j.php?MTID=m9c8f9627c8fde4e49764900ba38bfe30 [22:07:05] *** Quits: bwalker_ (~bwalker@ip70-190-226-244.ph.ph.cox.net) (Quit: Leaving) [23:01:50] *** Quits: johnmeneghini (~johnmeneg@pool-100-0-53-181.bstnma.fios.verizon.net) (Quit: Leaving.) [23:36:05] *** Joins: tomzawadzki (tomzawadzk@nat/intel/x-odgpvwdqqtqvzulh) [23:44:20] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [23:46:03] darsto: Hi Darek, will you provide you feedback again to iSCSI hotplug based on the update in Gerrit? [23:47:10] Shuhei: doing it atm [23:48:25] Thank you, no urgent but it will be great if you do today in your time.