[00:04:15] *** Quits: klateck (c0c69724@gateway/web/freenode/ip.192.198.151.36) (Ping timeout: 252 seconds) [00:27:21] *** Quits: lhodev (~lhodev@66-90-218-190.dyn.grandenetworks.net) (Ping timeout: 256 seconds) [00:33:23] *** Joins: klateck (c0c69724@gateway/web/freenode/ip.192.198.151.36) [00:33:47] *** Quits: klateck (c0c69724@gateway/web/freenode/ip.192.198.151.36) (Client Quit) [00:59:19] *** Joins: tkulasek (tkulasek@nat/intel/x-ezgathpiysdejrsk) [01:07:53] *** Joins: lhodev (~lhodev@66-90-218-190.dyn.grandenetworks.net) [02:10:05] *** Quits: dlw (~Thunderbi@114.255.44.143) (Remote host closed the connection) [02:10:42] *** Joins: dlw (~Thunderbi@114.255.44.143) [03:13:57] *** Joins: dlw1 (~Thunderbi@114.255.44.143) [03:13:58] *** Quits: dlw (~Thunderbi@114.255.44.143) (Read error: Connection reset by peer) [03:13:58] *** dlw1 is now known as dlw [03:31:46] *** Joins: bwalker (bwalker@nat/intel/x-xppypeefhbrktdos) [03:31:46] *** Server sets mode: +cnt [03:32:51] *** Joins: tsg (~tsg@134.134.139.72) [03:34:23] *** Joins: changpe1 (changpe1@nat/intel/x-tljefvjsypbhlilt) [03:35:19] *** Joins: gangcao (~gangcao@134.134.139.72) [03:37:20] *** Joins: lgalkax (~lgalkax@134.134.139.72) [03:37:56] *** Joins: mszwed (mszwed@nat/intel/x-fdnamkmnltggpnfp) [03:38:58] *** Joins: johnmeneghini (~johnmeneg@pool-100-0-53-181.bstnma.fios.verizon.net) [03:40:50] *** Quits: johnmeneghini (~johnmeneg@pool-100-0-53-181.bstnma.fios.verizon.net) (Client Quit) [03:41:22] *** Joins: pzedlews (~pzedlews@134.134.139.72) [03:46:57] *** Joins: pniedzwx (~pniedzwx@134.134.139.72) [03:48:58] *** Joins: vermavis (vermavis@nat/intel/x-jjychmipwvqglhpc) [03:49:59] *** Joins: jimharris (~jimharris@134.134.139.72) [03:52:30] *** Joins: ppelplin (~ppelplin@134.134.139.72) [03:53:31] *** Joins: sethhowe (sethhowe@nat/intel/x-nrveibqxlgfvzccr) [03:55:34] *** Joins: pbshah1 (~pbshah1@134.134.139.72) [03:57:37] *** Joins: kjakimia (~kjakimia@134.134.139.72) [03:58:03] *** Joins: pawelkax (pawelkax@nat/intel/x-bdotivrrpptavpjq) [03:58:59] *** Joins: pwodkowx (~pwodkowx@134.134.139.72) [03:59:34] *** Joins: ziyeyang (~ziyeyang@134.134.139.72) [04:00:05] *** Joins: peluse (~peluse@134.134.139.72) [04:08:17] *** Quits: dlw (~Thunderbi@114.255.44.143) (Ping timeout: 248 seconds) [04:54:11] *** Joins: lyan (~lyan@2605:a000:160e:2124:4a4d:7eff:fef2:eea3) [04:54:34] *** lyan is now known as Guest61292 [05:31:40] *** Joins: johnmeneghini (~johnmeneg@pool-100-0-53-181.bstnma.fios.verizon.net) [06:05:34] *** Joins: jkkariu (~jkkariu@134.134.139.72) [06:21:17] *** Quits: lhodev (~lhodev@66-90-218-190.dyn.grandenetworks.net) (Quit: My MacBook has gone to sleep. ZZZzzz…) [06:58:35] *** Joins: philipp-sk (~Philipp@ktnron0916w-lp130-02-76-66-162-159.dsl.bell.ca) [07:24:40] *** Joins: peluse_ (48d0c853@gateway/web/freenode/ip.72.208.200.83) [07:25:21] *** Quits: peluse2 (48d0c853@gateway/web/freenode/ip.72.208.200.83) (Ping timeout: 252 seconds) [07:28:21] johnmeneghini: trying now but uninstalled everything and reinstalled git bash to check out "as is" [07:48:24] *** ChanServ sets mode: +o peluse [07:48:46] johnmeneghini, I'm +1 on your patch now... see comments in GH [08:54:33] ehhh, there is some ugly race in bdev_nvme when using hotplug... [08:55:26] https://review.gerrithub.io/#/c/spdk/spdk/+/419093/14..15/lib/bdev/nvme/bdev_nvme.c [08:59:22] v14: I made mistake and switched 'hotplug_period' with 'hotplug_enabled' in hotplug poller setup evectivly enabling hotplug poller @ 1us period [08:59:40] this flooded the console with: [08:59:40] thread.c: 346:spdk_io_device_register: *ERROR*: io_device 0x200000066cc0 already registered [08:59:44] ehh.... [09:00:48] and the spdk_tgt aborted with bdev nvme "HotInNvme15556" :D [09:30:22] *** Quits: tomzawadzki (~tomzawadz@192.55.54.40) (Ping timeout: 264 seconds) [09:34:27] bwalker, two more changes to our dpdk fork that are crypto dependencies. Please take a peek when you have time (LOL) https://review.gerrithub.io/c/spdk/dpdk/+/418730 and https://review.gerrithub.io/c/spdk/dpdk/+/419033 [09:34:32] (small changes) [09:34:42] *** Joins: kjakimia_ (kjakimia@nat/intel/x-iguuhodowwpkpuyy) [09:35:07] *** kjakimia_ is now known as klateck [09:48:04] *** Joins: travis-ci (~travis-ci@ec2-54-167-177-247.compute-1.amazonaws.com) [09:48:05] (spdk/master) bdev: change return type of _spdk_bdev_enable_qos to void (Ziye Yang) [09:48:05] Diff URL: https://github.com/spdk/spdk/compare/706c57bf2f00...1f5c8233da1c [09:48:05] *** Parts: travis-ci (~travis-ci@ec2-54-167-177-247.compute-1.amazonaws.com) () [09:56:04] *** Quits: tkulasek (tkulasek@nat/intel/x-ezgathpiysdejrsk) (Ping timeout: 260 seconds) [10:33:59] peluse: SPDK_CRYPTO_HACK [10:34:22] good thing it's not SPDK_CRYPTIC_HACK [10:36:16] LOL, its that too I think :) [10:49:16] or SPDK_CYRYLLIC_HACK [10:50:29] I've been doing whole body cryotherapy a lot lately for sports recovery, many of my early patches still had "cryo" as shorthand for crypto :) I think maybe the froze some of my brain also! [11:00:29] bwalker, I know you haven't looked much at the crypto patch but we have talked about doing read decrypt in place and writes in our own buffer to avoid encrypting the buffer handed to us. I just realized that I have to do the same thing for decrypt also [11:00:45] if you can sanity check my last comment on https://review.gerrithub.io/c/spdk/spdk/+/403107/38 and see if it makes any sense to you that'd be great [11:00:57] I think with zcopy, you'd never decrypt in place anymore [11:01:33] yeah, I mention that in the comment but this is *supposed* to go in before zcopy, famous last words... [11:01:54] yeah - looking now [11:04:31] so you're trying to handle the case where you do a read from the underlying device [11:04:40] and it returns an iov with non-block size elements? [11:04:51] the total size is a block multiple, but the individual pieces aren't [11:05:06] well, hold off just a sec. Maybe I can still do this. Yeah, the scenario is what you just said [11:05:19] I think that's technical a real scenario [11:05:28] but I wouldn't worry about handling it at the moment [11:05:48] I can't imagine a bdev implementation that would return non-block multiple iov elements [11:06:02] incoming data, of course - since that's coming from the network [11:06:10] but data read from a bdev, probably not [11:06:16] I keep forgetting that I have iovs on one end and mbufs on the other (not LBAs) so yeah I should still be able to construct ops the way I imagined in my head [11:06:47] yeah, on the read I'm talking about the dest mem buffer [11:07:28] I've got something started already, I just confused myself somehow, go figure [11:09:29] I'll write a few more unit tests that have funky IOVs like this just to make it super clear [11:09:30] thanks [11:16:37] bwalker: e.g. buffers allocated by the bdev layer have unaligned len now [11:16:43] ping darsto> bwalker: what's the purpose of spdk_bdev_io_set_buf being public? [11:17:04] darsto> and why does it set iov_len to an arbitrary len? it should be at least blocksize aligned [11:26:27] heh, ok got the perfect UT already :) [12:37:23] *** Joins: lhodev (~lhodev@66-90-218-190.dyn.grandenetworks.net) [12:49:42] *** Joins: alekseymmm (050811aa@gateway/web/freenode/ip.5.8.17.170) [13:30:16] darsto: are you talking about my patch that changes spdk_bdev_io_set_buf? [13:30:40] or the one currently checked in [13:31:36] because my patch is making it so that bdev modules can call spdk_bdev_io_set_buf [13:32:05] you really don't want to re-align a module's pointer - the module could be pointing to a very specific location where the data needs to end up [13:32:28] I do verify alignment, but I'm not sure I should even be doing that [13:33:04] now, if the buffer comes from the bdev buffer pool, it does handle alignment. I just moved that logic into spdk_bdev_io_get_buf [13:33:14] and spdk_bdev_io_put_buf - instead of having it in the set call [13:35:59] i'm talking about what we have currently on master [13:36:14] oh - well I have a patch out that changes it entirely [13:36:20] because I didn't think it made sense either [13:36:26] it's kind of broken now [13:36:33] https://review.gerrithub.io/#/c/spdk/spdk/+/419025/ [13:36:56] I have two open questions on my patch - 1) I should probably remove the alignment check in the set path [13:37:14] and 2) should I verify that the total length of the buffer provided is greater than or equal to the size of the I/O request? [13:38:16] we decided it would be most intuitive of the iov_len was set to the length requested by the user when they called spdk_bdev_io_get_buf [13:38:24] as opposed to the "actual" size of the buffer obtained from the pool [13:38:43] we store the real buffer size in internal.buf_len anyway [13:40:20] peluse: what in the build system is still blocking your crypto patch from running? [13:40:32] is there something I can merge to get that going? [13:45:13] I just threw two things up on the miscellaneous trello board [13:45:19] if someone wants a fun project [13:45:29] 1) Make sure the LTO stuff I added awhile back is still working [13:45:36] 2) Add options to do PGO [15:05:25] let me check... [15:19:12] *** Quits: alekseymmm (050811aa@gateway/web/freenode/ip.5.8.17.170) (Quit: Page closed) [15:24:43] bwalker, here's what needs to merge first. Then I need to rebase and test it all together, then I'll pull the RFC out of the commit message. Right now I have it gutted for a little rework so don't suspect I'll be ready to rebase til EOD tomorrow. But, here's the dependent patches: [15:25:38] https://review.gerrithub.io/c/spdk/dpdk/+/419033 https://review.gerrithub.io/c/spdk/dpdk/+/418730 https://review.gerrithub.io/c/spdk/spdk/+/404983 [15:26:48] and this little pissy UT thing that I might need to abandon depending on when your UT simplify patch goes through so this can wait until its really a squeaky wheel https://review.gerrithub.io/c/spdk/spdk/+/418549 [15:30:03] *** Quits: philipp-sk (~Philipp@ktnron0916w-lp130-02-76-66-162-159.dsl.bell.ca) (Ping timeout: 256 seconds) [15:42:01] *** Quits: Guest61292 (~lyan@2605:a000:160e:2124:4a4d:7eff:fef2:eea3) (Quit: Leaving) [15:50:11] *** Joins: Johnson_ (0cda5282@gateway/web/freenode/ip.12.218.82.130) [15:51:38] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [15:52:58] Can I please know the way to enable logging and set log levels? [16:13:26] ya know, that's a great question. I spend so much time in gdb I never even look at log messages. the following 3 macros are commonly used to log messages within SPDK but honestly I'm not sure what the right way is to adjust levels [16:13:27] #define SPDK_NOTICELOG(...) \ [16:13:27] spdk_log(SPDK_LOG_NOTICE, __FILE__, __LINE__, __func__, __VA_ARGS__) [16:13:27] #define SPDK_WARNLOG(...) \ [16:13:27] spdk_log(SPDK_LOG_WARN, __FILE__, __LINE__, __func__, __VA_ARGS__) [16:13:29] #define SPDK_ERRLOG(...) \ [16:13:31] spdk_log(SPDK_LOG_ERROR, __FILE__, __LINE__, __func__, __VA_ARGS__) [16:19:49] :-). Thanks, peluse. [16:22:54] Johnson_, sure, sorry I don't have a better answer that I really should know :( Hopefully someone else can chime in with the rest soon.... [16:27:40] peluse: No problems. [16:40:51] *** Quits: Johnson_ (0cda5282@gateway/web/freenode/ip.12.218.82.130) (Ping timeout: 252 seconds) [18:45:42] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Ping timeout: 252 seconds) [19:05:46] *** Joins: dlw (~Thunderbi@114.255.44.143) [19:10:19] reminder: Asia friendly community meeting in a few hours from now... https://trello.com/b/DvM7XayJ/spdk-community-meeting-agenda [19:13:54] *** Joins: dlw1 (~Thunderbi@114.255.44.143) [19:13:54] *** Quits: dlw (~Thunderbi@114.255.44.143) (Read error: Connection reset by peer) [19:13:55] *** dlw1 is now known as dlw [19:17:37] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [19:33:00] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Ping timeout: 252 seconds) [19:59:30] *** Joins: philipp-sk (~Philipp@ktnron0916w-lp130-02-76-66-162-159.dsl.bell.ca) [20:30:42] *** Joins: dlw1 (~Thunderbi@114.255.44.143) [20:32:20] *** Quits: dlw (~Thunderbi@114.255.44.143) (Ping timeout: 245 seconds) [20:32:20] *** dlw1 is now known as dlw [20:53:23] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [20:57:07] seems to be an issue with the WebEx link... give me a few minutes [20:57:29] OK Paul [20:58:12] This is the link I have. [20:58:14] https://intel.webex.com/intel/j.php?MTID=m6aabab242b8b52729cf97e64348d64e8 [20:58:25] It says the meeting has been canceled [20:59:01] yeah, for some reason the whole series was cancelled for Asia. Use this for tonight [20:59:02] https://intel.webex.com/meet/PELUSE [20:59:21] Maybe you should email out this new WebEx link. [21:01:26] *** Joins: bwalker_ (~bwalker@ip70-190-226-244.ph.ph.cox.net) [21:01:26] *** ChanServ sets mode: +o bwalker_ [21:01:27] dk [21:01:38] whoops [21:03:51] if you have a new permanent meeting link I can update the website [21:18:08] sethhowe, can you prioritize this one https://review.gerrithub.io/c/spdk/spdk/+/414861/ and vote once you're comfortable [21:25:37] *** Quits: johnmeneghini (~johnmeneg@pool-100-0-53-181.bstnma.fios.verizon.net) (Quit: Leaving.) [21:42:44] *** Quits: philipp-sk (~Philipp@ktnron0916w-lp130-02-76-66-162-159.dsl.bell.ca) (Ping timeout: 255 seconds) [22:09:20] *** Quits: bwalker_ (~bwalker@ip70-190-226-244.ph.ph.cox.net) (Quit: Leaving) [22:31:09] *** Quits: sage_ (~quassel@2607:f298:5:101d:f816:3eff:fe21:1966) (Ping timeout: 276 seconds) [22:31:46] *** Joins: sage_ (~quassel@2607:f298:5:101d:f816:3eff:fe21:1966) [23:14:06] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Ping timeout: 252 seconds) [23:40:45] *** Joins: tomzawadzki (~tomzawadz@192.55.54.44)