[00:01:27] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [01:10:01] *** Joins: tomzawadzki (~tomzawadz@134.134.139.83) [04:35:06] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [04:58:21] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [05:27:10] *** Quits: drv (daniel@oak.drv.nu) (Remote host closed the connection) [05:28:18] *** Joins: drv (daniel@oak.drv.nu) [05:28:19] *** ChanServ sets mode: +o drv [06:40:33] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [07:01:22] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [07:40:16] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [07:44:23] *** Joins: lhodev (~Adium@inet-hqmc04-o.oracle.com) [08:06:00] Anyone here have any strong feelings regarding adoption of a policy for the return value from spdk_app_start()? I've altered the internals of that lib function such that it no longer exit()'s on startup failures, but instead returns a value (-errno) to the caller. That appears to open a can of worms: how does the caller of spdk_app_start() make the distinction between a failure code returned by spdk_app_start() due to some internal me [08:06:00] chanism failing such that the caller's start_fn NEVER even gets to run versus the return status value via spdk_app_stop()? grep'ing through the SPDK repo, I see a variety of values passed in spdk_app_stop(): from 0 (virtually if not always confers success), -1 (failure), an errno value, and a counter value (number of failures). There are also several uses of spdk_app_start() whose return value is ignored (primarily in test code) and on [08:06:00] e, um, more challenging use in C++ code (rocksdb) in which case I'm thinking an exception should be thrown. I would propose that we constrain the return values supported via spdk_app_stop() to be greater than or equal to zero to make the distinction. Thoughts? [08:33:10] lhodev: that makes sense to me (internal errors are negative, user return code passed to spdk_app_stop() should be >= 0) [08:34:17] especially since most of the apps return the code from main(), which should generally not be negative [08:34:48] lhodev: +1. That plays nicely with Unix error reporting rules [08:45:22] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [08:47:02] Thank you for the feedback. I won't conceal I have at least a little concern with respect to caller behavior when I make this change; esp. those that are calling spdk_app_stop(-1) as that would appear as an internal failure with errno -EPERM. I'll just have to spend some extra time I guess scrutinizing those. In line with this proposed change, I was thinking of also modifying spdk_app_stop() such that it would perform an assert() for t [08:47:03] he case of a caller attempting to pass an -1. I'd alter the CHANGELOG respectively, and seek out any other docs to reflect this as part of the submitted patch. [08:47:34] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [09:00:22] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [09:22:30] drv: I assigned the cpumask patch to you since you'd already been reviewing it [09:22:46] ok, I think it was in pretty good shape, will take another quick look [09:23:22] at least in terms of a good public API - I haven't looked too closely at the actual implementation of the cpumask functions yet, but we can improve that later if needed [09:43:13] bwalker, please see quick question on https://review.gerrithub.io/#/c/390923/ - thanks! [09:48:25] *** Quits: tomzawadzki (~tomzawadz@134.134.139.83) (Ping timeout: 260 seconds) [10:06:34] done [10:16:48] drv: can you do trigger a doc update on spdk.io [10:17:07] not right now, since my keys and everything are on my dev machine at work, and I turned it off before I left [10:17:17] I am sitting next to it [10:17:26] well, unless you know my disk encryption passphrase... :) [10:17:31] that's a problem [10:17:42] I'll update the docs then [10:17:42] we should get more people spun up on how to do doc updates anyway [10:17:53] I've done it before, I just don't want to forget something [10:17:56] (or really just automating it woudl be better) [10:18:06] just ./update-doc.sh or whatever it's called in spdk.github.io [10:18:42] ok I ran that [10:18:48] so I just commit that [10:18:53] it should stage everything (git diff --cached to verify) [10:18:54] yeah [10:19:01] do you want me to even bother with a review? [10:19:16] I usually push it as a review just to verify it looks OK, then +2 it myself and push [10:19:20] ok [10:19:31] (push via gerrithub) [10:19:49] you don't have a nice way to generate the commit message do you [10:21:04] I just copied one of your other ones [10:21:07] no, I just copy the latest commit ID [10:22:03] we could make the script automatically check out a branch and make a commit or something [10:22:12] but at that point, might as well go all the way and automate it fully [10:22:25] yeah we really should fully automate - just pull and update every evening or something [11:01:49] *** Quits: lhodev (~Adium@inet-hqmc04-o.oracle.com) (Remote host closed the connection) [11:02:59] *** Joins: lhodev (~Adium@66-90-218-190.dyn.grandenetworks.net) [11:22:54] *** Quits: lhodev (~Adium@66-90-218-190.dyn.grandenetworks.net) (Quit: Leaving.) [11:31:41] drv: when implementing an rpc handler, how long is the spdk_jsonrpc_request *request valid for? Just during the handler? I need to do an asynchronous operation and complete the RPC later [11:45:39] it's valid until you call spdk_jsonrpc_end_result() - you can stash the request object somewhere and call it asynchronously if needed [11:57:11] ok cool [13:18:18] *** Joins: lhodev (~Adium@inet-hqmc02-o.oracle.com) [13:30:56] *** Joins: lhodev1 (~Adium@66-90-218-190.dyn.grandenetworks.net) [13:30:58] *** Quits: lhodev (~Adium@inet-hqmc02-o.oracle.com) (Remote host closed the connection) [13:36:47] *** Quits: lhodev1 (~Adium@66-90-218-190.dyn.grandenetworks.net) (Ping timeout: 248 seconds) [13:39:52] bwalker: can you re-check https://review.gerrithub.io/#/c/391603/13/doc/vhost.md@20 [13:45:08] updated [14:13:13] this epoll thing is actually going to simplify the iscsi target a lot [14:13:29] yeah [14:14:01] *** Joins: lhodev (~Adium@inet-hqmc03-o.oracle.com) [14:14:09] i forgot that in the common case, the task status gets sent with the datain, so we can just always flush each pdu immediately [16:59:46] *** Parts: lhodev (~Adium@inet-hqmc03-o.oracle.com) ()