[05:09:07] *** Joins: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) [06:34:01] *** Joins: johnmeneghini (~johnmeneg@pool-96-252-112-122.bstnma.fios.verizon.net) [06:34:01] *** Quits: johnmeneghini (~johnmeneg@pool-96-252-112-122.bstnma.fios.verizon.net) (Client Quit) [06:46:39] *** Joins: lhodev (~Adium@inet-hqmc05-o.oracle.com) [07:15:26] *** Quits: lhodev (~Adium@inet-hqmc05-o.oracle.com) (Quit: Leaving.) [07:29:27] *** Joins: lhodev (~Adium@inet-hqmc05-o.oracle.com) [07:53:31] Hey guys, up to this point I've only cloned an SPDK repo using https. On the spdk.io/development page, I'm perplexed by the section about https vs. ssh public keys. I have uploaded an ssh public key, but I'm confused about pushing changes. If I want to try and push changes to SPDK for consideration, am I supposed to try to clone via ssh://$my_github_id@review.gerrithub.io/spdk/spdk ? My attempts clone using that always fail with a "No [07:53:31] route to host". Attempting the suggested "ssh -p 29418 $my_github_id@review.gerrithub.io" results in the same "No route to host." Then, there's the SPDK development instructions about cloning via "https" and specifying a password. I'm sorry, but I just don't get it. [07:58:15] lhodev, so I use https but others use ssh so either will work. How you clone doesn't make any difference, its this either way "git clone https://review.gerrithub.io/spdk/spdk" [07:58:57] and if you follow the directions for setting up your .git/config file [07:58:58] [remote "review"] [07:58:59] url = https://review.gerrithub.io/spdk/spdk [07:58:59] push = HEAD:refs/for/master [07:59:14] then when you push, you just do "git push review" [07:59:32] if you use ssh, the url in the 'review' section will be different though [08:00:08] I can change mine over here in a bit and let you know exactly what it looks like and any gotchas but I'm in the middle of editing/pushing stuff so don't want to jack that up :) [08:00:18] or, someone else who uses ssh may pop in here soon... [08:03:01] lhodev: you probably need ssh config changes if you're behind a corporate firewall [08:03:36] So, given that you've used https to clone, when you attempt to push your changes, then you either get prompted for the http password you generated (or you've set up the 'git credential helper' to achieve that? [08:03:52] Jim, I am behind a firewall, but I have my gitproxy stuff set up and it *seems* to work fine. [08:04:30] I did create an .ssh/config rule also with my github ID to avoid accidentally having it send my local Linux ID instead. [08:09:40] hmmm - are you able to ssh out from behind your firewall to anywhere else? [08:12:05] seems like there's a more fundamental problem since you can't do straight ssh either (which won't use your gitproxy) [08:14:45] What's more odd is that I disconnected from my VPN and attempted to do the operations straight from my network at home, but still ran into the same trouble. [08:17:13] I'll experiment with that some more later. I'll just use https for now. [08:27:23] lhodev, yeah, I've used ssh behind a firewall and it was a bit of a PITA [08:43:05] bwalker, drv jimharris : chain updated, correctly I think. Only a few small things I didn't change, see comments & let me know what you think... [08:55:54] FYI some sort of unrelated FIO error on https://review.gerrithub.io/#/c/372541/ Pls remove -1 label at some point [09:14:38] lhodev: I use https and chose to wrote the directions at spdk.io/development based on https precisely because I thought it was more likely that people would have https set up behind their corporate proxy than ssh [09:14:43] so just use https all the time [09:24:20] Thanks Ben. I'll plan on just using https. [09:57:04] jimharris: can you look at https://review.gerrithub.io/#/c/374539/ and the one after it? just those two - I'm going to rebase the rest of the series on top of some patches drv just submitted [10:07:16] couple of questions [10:07:41] in NEED_BUFFER state, if no buffers are available, should we put the rdma_req back at the head of the list instead? [10:08:33] actually that's my only question [10:08:40] let me look - I think that's potentially a great catch [10:08:45] not a small patch :) [10:08:50] this state machine made me think about so many corner cases that I don't think were handled before [10:09:54] the first version was like 1000 lines - it was hard fought to get it down to the ~275 it is today [11:32:17] peluse: I put some general comments on the blob cli review - didn't get all the way through it, but it looks pretty awesome [11:38:26] drv, cool thanks!! [11:39:57] peluse: do you find the startup time to be annoying when using it? [11:40:45] I have some thoughts on how to improve that, but they're all complex [11:40:47] * peluse finds anything that's not instant annoying [11:41:51] OK, I'm interested... isn't it the same startup time that all our apps suffer from or do you mean something different? [11:42:26] same problem, but it's more annoying for a CLI because a human is sitting there waiting on it for each command [11:42:38] yeah, for sure [11:43:06] let me know what your thoughts are... [11:43:26] I think you could start up the nvme_stub thing that Jim added [11:44:23] or I could just change the UI to not be a CLI and be a basic text menu driven thing [11:45:05] but I do think I see how the stub idea could work too [11:45:07] if the nvme_stub is running and the blob cli is running in multiprocess mode (shared memory), then it should start real quick [11:45:38] you'd want to make that optional, or "advanced" usage [11:45:55] "turbo blob" :) [11:46:54] good thoughts for next rev though I think, it's big enough already but easy enough to not be a totally crazy review... [11:48:47] anyone tried mixing single and dual rank DIMMs on an Intel mobo? I'm about ready to pull my hair out - what little there is of it!! [13:27:22] sounds complicated - I just stick to software :) [14:13:09] jimharris: when you get a chance, please check out my nvmf series starting at https://review.gerrithub.io/#/c/374733/ [14:13:20] this will enable some refactoring that bwalker is working on [14:23:53] yeah, we need software defined DIMMs :) [14:38:44] haha, don't give them any ideas [15:56:29] *** Quits: lhodev (~Adium@inet-hqmc05-o.oracle.com) (Quit: Leaving.) [16:56:25] bwalker, drv: i updated the virtio patch - mostly changes to the README's list of todo items based on your feedback so far [17:00:07] drv: i'm not sure i care for the DEBUG ifdefs in the latest rev of the reactor rusage patch [17:00:48] i understand the reason - i was hoping if we just call this once per second that it would basically be a nop [17:08:55] it's about 400 core clocks on my 2.3GHz proc - or about 170ns [21:43:20] jimharris: I'm OK with keeping it unconditionally enabled if you prefer [21:44:40] it does potentially impact the calculation of when the reactor can go to sleep (depending on the user-configured max_delay_us