[00:13:18] *** Joins: Param (~Param@106.51.65.217) [01:43:50] *** Quits: Param (~Param@106.51.65.217) (Quit: Param) [02:11:14] *** Joins: tkulasek (~tkulasek@192.55.54.40) [02:30:34] *** Joins: Param (~Param@106.51.65.217) [02:39:30] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Ping timeout: 260 seconds) [02:56:45] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Quit: Textual IRC Client: www.textualapp.com) [03:58:03] *** Quits: Param (~Param@106.51.65.217) (Quit: Param) [04:23:29] *** Joins: Param (~Param@106.51.65.217) [04:40:27] *** Quits: tkulasek (~tkulasek@192.55.54.40) (Ping timeout: 240 seconds) [04:51:58] *** Joins: tkulasek (~tkulasek@192.55.54.40) [05:23:31] *** Quits: Param (~Param@106.51.65.217) (Quit: Param) [06:41:26] *** Quits: tkulasek (~tkulasek@192.55.54.40) (Ping timeout: 256 seconds) [07:20:19] It's 15:00 still, that was a copy/paste error. It's been updated [07:44:02] *** Joins: tkulasek (~tkulasek@192.55.54.40) [08:15:59] *** Joins: Param (~Param@106.200.253.73) [08:19:52] *** Quits: Param (~Param@106.200.253.73) (Client Quit) [08:28:30] *** Joins: Param (~Param@106.200.253.73) [08:28:42] drv: what is the difference when building using autobuild.sh and autopackage.sh? [08:28:48] http://spdk.intel.com/public/spdk/builds/review/19d355a6da11aa4b519c36ab6ec583ca5d74b56e.1520002897/centos6/build.log [08:29:14] I don't know why it is failing... [08:58:36] pwodkowx: autopackage.sh builds with optimizations on (CONFIG_DEBUG=n) - maybe that is the difference here? [09:00:10] :/ [09:00:53] Any idea how to overcome those issues ? Can you update compile on Centos machine? [09:01:25] well, the goal is to build with the compiler shipped with the distro, so this is the version we're stuck with [09:01:32] this is a little odd, though - we should not have strict aliasing enabled [09:01:38] I wonder if that has changed somewhere in DPDK [09:02:31] maybe DPDK does actually leave strict aliasing enabled - I just see a few Makefiles where they explicitly disable it with -fno-strict-aliasing [09:03:02] a workaround could be to patch the particular Makefile that's an issue with a similar CFLAGS addtion of -fno-strict-aliasing [09:41:40] drv: https://review.gerrithub.io/c/401314/ made the changes.. [09:41:49] thanks, I'll re-check it [09:41:57] *** Quits: Param (~Param@106.200.253.73) (Quit: Param) [10:04:40] *** Joins: Param (~Param@157.49.128.157) [10:05:26] drv: I see that u have verified.. [10:05:50] yep, looks OK to me - just needs a review from another maintainer now [10:06:28] okay.. after that approval will the card be automatically merged or should i rebase it? [10:07:24] as long as the Gerrit page doesn't say "Merge conflict", it will be automatically rebased when we submit it - so you don't need to do anything else [10:08:32] in gerrit page i see this under merge conflicts haeading nvmf: add histogram instrumentation to nvmf_tgt and perf, test [10:08:32] nvmf: add Namespace attribute notice support [10:12:41] that's ok, those are other outstanding patches that haven't been merged yet either [10:12:50] as long as they are not merged first, you won't need to do anything [10:29:35] *** Quits: tkulasek (~tkulasek@192.55.54.40) (Ping timeout: 240 seconds) [10:33:31] sure. thanks.. [10:34:43] what is the next card that i can work on [10:50:57] *** Quits: johnmeneghini (~johnmeneg@pool-96-252-112-122.bstnma.fios.verizon.net) (Ping timeout: 240 seconds) [11:15:38] drv: do we have some iscsi_tgt issue? I noticed crashes of this app during last week. [11:16:48] pwodkowx: it does seem like there is some intermittent iscsi_tgt failure [11:17:00] Ziye has posted some patches that I think are related (just merged today), so we should keep an eye out now - if it is still failing, maybe it's not fixed yet [11:17:59] ok, I will rebase and observe [11:20:39] drv: I had overlooked that you, yourself, had uploaded a patch (#2) to my https://review.gerrithub.io/#/c/401243/, and I think I just committed the identical change. Sorry 'bout that. I've never seen nor expected that kind of scenario where someone other than the original author follows up with a patch. No harm, no foul. Just a newly noted experience for me. [11:20:56] hey. I'll be on a vacation the entire next week. [11:21:08] I couldn't set in in outlook for some reason [11:23:00] lhodev1: no problem, looks like you did exactly the same change, so that's good :) [11:23:22] drv: I meant, https://review.gerrithub.io/#/c/402165/. Well, clearly you understood. Again, sorry 'bout that. [11:35:43] drv: can you look at https://review.gerrithub.io/#/c/392607/ and push it if you're ok with the changes? [11:51:57] also https://review.gerrithub.io/#/c/400955/ [12:09:14] ok, both merged [12:20:51] jimharris: looks like c1174e6895ca44242d12b2e5f0742f84ccbf0b8f had not been rebased in a while and added back some spdk_blob_data references [12:20:57] do you want to fix that up, or should I take a look? [12:21:22] if you wouldn't mind fixing that up - I'd appreciate it [12:21:50] ok [12:29:32] the unit tests are broken too... [12:29:53] ok - then maybe it just needs to wait until he's back [12:31:09] I'll push my current fixups as a review, and then revert that change for now [12:32:29] this fixes compilation but not the unit tests: https://review.gerrithub.io/#/c/402351/ [12:33:21] and here's the revert: https://review.gerrithub.io/#/c/402352/ [12:52:06] jimharris: revert has passed the test pool - if you +2 it, we can merge it [12:52:58] done [13:43:03] jimharris: your "queue sync" patch looks ok to me, but it has merge conflicts that need to be resolved: https://review.gerrithub.io/#/c/401257/ [13:43:24] yeah - I'm looking at that now [13:45:04] not sure what Gerrit's problem is - no merge conflicts when I did the rebaes [13:53:18] yeah, sometimes it reports them and git can happily rebase with no drama [13:54:21] it's good to get a test run in with the rebase anyway, though - as we can see from recent experience :) [13:54:47] did someone say freebase? [13:54:59] oh, my bad, rebase... sorry :) [13:55:41] haha [13:56:44] https://review.gerrithub.io/#/c/400894/ - NVMe namespace UUIDs [13:57:03] are you sure we don't want to do this at the bdev level instead? [13:57:29] even if today, most bdev modules don't specify their own uuid - i'm thinking if we specify this at the bdev level, then other upper layer protocols can use it too [13:57:36] I started on a series to add uuid to bdev [13:57:46] not sure why that other patch got bumped up again [13:58:09] should i mark it -1 for now? or are you thinking we'd have both? [13:58:25] yeah, please -1 it with your reasoning - I think the bdev approach should be ok [13:58:30] (but I'd still be ok with doing both as well) [13:58:32] will do [15:39:41] jimharris, OK able to use a generic mempool for my mbufs and set my own spdk alloc'd DMA buffer and successfully encrypt/decrypt, don't see any reason why there'd be a limit on length unless there's something in the PMD that pukes over 2K in one mbuf. Won't know til I try it though.... [15:42:09] *** Quits: darsto_ (~dstojacx@89-68-135-211.dynamic.chello.pl) (Ping timeout: 256 seconds) [15:44:16] yeah - i'd be surprised if it's limited to 2k [15:44:56] that might just be related to the default mbuf size for mbufs in an rte_pktmbuf_pool [15:46:27] I'm sure... have a lot of code to write before I can test it though, right now I was just hacking in small enough buffers that I could set/confirm via inspection. Now I have to plumb all this into the I/O path and add some code to do the confirmation instead of my crappy eyes that can't read more than 16 bytes reliably :) [15:47:33] you should be able to use bdevio as a sanity check [15:47:40] yup [15:47:43] it's our quasi-unit tests for the bdev layer [15:47:54] cool [16:07:39] drv: what is the next card that I can start working on., [16:13:40] drv: that e-mail thread with stephen - that's a reason we should continue to register vfio addresses that match the physical address [16:13:56] otherwise we'll need to keep separate page tables for uio and vfio enabled devices [16:17:07] hi Param - do you have a Trello handle? [16:17:25] wanted to add you to the NVMe-oF card that you just completed [16:20:43] Param: you're welcome to pick up any cards that are not currently in progress - there should be several more on the NVMe-oF board if that's what you're interested in working on [16:24:08] drv: what about this one for Param? https://trello.com/c/yJOeS6q0 [16:24:16] it's wait for outstanding I/O to complete when pausing subsystem [16:24:52] sounds complicated to me, so only if you're up for a challenge :) [16:26:49] it's complicated for sure but a perfect card to get to know the nvme-of target inside and out :) [16:28:26] jimharris, drv : just so I'm positive (sure looks like it) but can I always count on bdev_io's, when they get to my crypto vbdev, having their iovector fields populated? [16:31:05] peluse: there's the whole get_buf thing for reads, but otherwise yes [16:31:19] jimharris: can you take another look at https://review.gerrithub.io/#/c/401081/ - I just added a comment [16:32:33] drv, OK, I'll have to refresh my memory on the get_buf thing but sounds like I can march forward expecting to have valid io vectors [16:33:02] peluse won't need to worry about get_buf [16:33:19] because for the read case, he'll decrypt the data on the way back [16:33:32] good point, for a vbdev it should be always populated [16:33:39] yup [16:33:44] since the bdev you are layered on top of will always retrieve it [16:33:44] not on the way down but on the way back up [16:33:50] yep [16:34:10] I'm going to get tricky though and decrypt on write and encrypt on read :) [16:35:03] are you working for the NSA? ;) [16:35:13] LOL [17:46:26] *** Quits: Param (~Param@157.49.128.157) (Quit: Param) [19:19:55] *** Joins: Param (~Param@157.49.172.241) [19:34:12] Hi. I have a trello handle. How do i add boards from SPDK to my handle [19:42:01] *** Quits: Param (~Param@157.49.172.241) (Quit: Param) [22:35:37] *** Joins: Param (~Param@106.51.65.217) [23:19:20] *** Joins: darsto_ (~dstojacx@89-68-135-211.dynamic.chello.pl) [23:19:43] *** darsto_ is now known as Guest468