[00:24:52] sispdk: yes, there's raid0 available as well [00:25:40] i could point you to a guide on spdk.io, but raid is actually undocumented, ha [00:26:44] we need to write it up [01:43:48] dartso : i see , thanks for info. what the raid module called as so that i can look in to the codebase [03:37:23] *** Quits: sidspdk (10f2ea15@gateway/web/freenode/ip.16.242.234.21) (Ping timeout: 256 seconds) [03:52:18] *** Joins: johnmeneghini (~johnmeneg@pool-108-20-29-249.bstnma.fios.verizon.net) [03:56:27] *** Quits: johnmeneghini (~johnmeneg@pool-108-20-29-249.bstnma.fios.verizon.net) (Ping timeout: 240 seconds) [05:52:58] *** Joins: johnmeneghini (~johnmeneg@pool-108-20-29-249.bstnma.fios.verizon.net) [05:57:07] *** Quits: johnmeneghini (~johnmeneg@pool-108-20-29-249.bstnma.fios.verizon.net) (Ping timeout: 240 seconds) [06:25:27] *** Joins: darsto_ (~darsto@89-78-174-111.dynamic.chello.pl) [06:26:27] *** Quits: darsto (~darsto@89-78-174-111.dynamic.chello.pl) (Ping timeout: 240 seconds) [06:29:47] *** Joins: darsto (~darsto@89-78-174-111.dynamic.chello.pl) [06:30:31] *** Quits: darsto_ (~darsto@89-78-174-111.dynamic.chello.pl) (Ping timeout: 260 seconds) [06:52:13] sidspdk: sorry, I missed your message. The raid functionality itself is in lib/bdev/raid. [06:52:30] you could also issue `$ ./scripts/rpc.py construct_raid_bdev -h` to see RPC usage [09:04:20] jimharris: pwodkowx: Good morning (and evening) guys. Do we have a quorum? [09:07:48] i'm here [09:08:01] we probably want bwalker too [09:09:47] While we wait for bwalker, do I understand correctly that the spdk cli and rpc python scripts absolutely require python3 -- i.e. not python2 compatible ? [09:22:01] they are python2 compatible (at leas should be) [09:22:30] we require they will work for 2 and 3 with python3 as default [09:24:31] I'm here [09:26:10] bwalker: https://review.gerrithub.io/#/c/spdk/spdk/+/430608/ :) [09:26:37] sorry it was stronger than me :P [09:27:11] hmm, not all of these tests are read-only [09:27:20] the astyle test modifies the files in place [09:27:27] I think you have to run that one in serial up front [09:28:46] good point, can be done [09:28:53] other than that, looks great [09:29:57] just wondering why pep8 is so long [09:30:06] it's written in python [09:30:36] LOL :) [09:31:10] lhodev, jimharris, bwalker: I need to go in 10minutes, is there something to talk about examples packages ? [09:31:47] the issue is resolving name conflicts when we flatten the directory structure for the binaries during install right? [09:32:03] and which example binaries we need for 18.10 [09:32:13] I think you can go small and expand later [09:32:18] adding to the list is backward compatible [09:32:34] just nvme/perf and nvme/identify seem good to me for now [09:32:38] Right. While prepending, for example, "perf" with "spdk_example_perf" doesn't have any conflicts, we run into an issue where we have a couple "hello_world" examples. [09:33:42] well the current directory structure is examples// [09:33:52] so can you just name them spdk__ [09:34:03] then we won't have any name conflicts because it's the same as the directory path [09:34:04] For example, jimharris advocated installing both nvme/hello_world and bdev/hello_world. [09:34:32] I kind of like having them all start with spdk so when they're installed you can type spdk and hit tab [09:34:35] to list them all [09:34:40] I guess we could retrieve the directory components as bwalker proposes to form the name. [09:34:40] but it is more typing for sure [09:34:57] bwalker: dpdk does that with their naming convention of examples (i.e. prepends dpdk_example_) [09:35:22] I don't think "example" is necessary, but instead we could use the directory [09:35:32] pretty much the same idea though [09:35:58] +1 for bwalker idea [09:36:09] bwalker: I'd like to retain example as not only does that match the DPDK's naming convention, it'll also help when we get the pieces in place to provide examples source and make files to build them. [09:36:20] it would be easy to point for proper source [09:37:00] bwalker: FWIW, I've seen some other very long-named entities in /usr/bin, so we wouldn't be the first ;-) [09:37:46] my only concern lhodev is that right now we're not doing a good job of deciding what's an "example" and what's really a utility [09:38:05] for instance, nvme/perf and nvme/identify are fine as examples, but they're also useful tools in their own right [09:38:29] bwalker: Fully agree, but as I'm desperately hoping to make this all happen based on 18.10..... [09:38:38] same thing with the fio_plugin [09:38:50] I don't want to introduce any significant changes. [09:39:17] so can we do most of them with "example" in the name, but have a special case for nvme/perf and nvme/identify for now [09:39:30] knowing that we should be moving those to the app directory instead (at least I think we should) [09:40:03] otherwise, if you put example in the name now [09:40:09] in 19.01 we'll end up changing it [09:40:21] which is the kind of churn we're trying to avoid [09:41:35] any chance to decide which application will converted from test or example app to tool ? We can do this only in package for now. [09:41:52] those two I listed, plus the fio_plugin are the only candidates I see [09:41:55] Can we decide now precisely which ones we will install for 18.10 ? jimharris didn't think we needed to ship them all. [09:41:55] but let me look harder [09:42:23] ok, first - are we shipping any of the fio plugins? [09:42:29] those are shared libraries so would be a different process [09:42:30] bwalker: We're currently in the spdk.spec file NOT building with fio. [09:42:39] ok, so let's ignore those [09:43:19] I'm fine with any solution but I need to know final decision to make the change in spec file [09:43:39] bdev/hello_world, blob/hello_world, nvme/arbitration, nvme/cmb_copy, nvme/hello_world, nvme/hotplug, nvme/nvme_manage, nvme/reserve are all purely examples in my opinion [09:43:42] and will remain as examples [09:43:47] pwodkowx: Agreed! And as soon as possible. [09:44:10] blob/cli, ioat/perf, ioat/verify, nvme/identify, nvme/perf are candidates for becoming "utilities" [09:44:45] also scripts/spdkcli is really a "utility" at this point, not a script [09:44:59] i.e. it's something you'd want to install [09:45:01] I will read this conversation tommorow. It would be great to have it also in trello or via email. [09:45:09] Must go. Bye [09:45:13] Let's please come to consensus on what we should minimally ship for this first pass. Like jimharris, I don't think we *need* to ship all of the examples, esp. since we are not providing source the first go round. [09:45:34] if we're not shipping source, I don't think we need to ship *any* examples [09:45:39] the examples are only useful as source [09:45:51] bwalker: except for perf and identify ? [09:46:03] well I'm saying I don't think those should be counted as examples [09:46:26] that's the two lists I just made - "examples" vs. "utilities" [09:46:38] utilities are worth packaging as binaries [09:46:43] examples are only worth packaging as source [09:48:01] so we mostly have to wait for others to weigh in on whether they agree with my lists [09:48:18] bwalker: so you advocate that we only ship blob/cli, ioat/perf, ioat/verify, nvme/identify, nvme/perf as utilities (without spdk_example_ prefixes)? and hold off on the other examples until 19.01 ? [09:48:30] I say for this first go around, we just package nvme/perf as spdk_nvme_perf and nvme/identify as spdk_nvme_identify [09:48:35] and hold the rest for 19.01 [09:48:58] jimharris: your 5 cents? [09:49:15] and we can just package them in the same package as spdk_tgt imo [09:49:15] sorry - finally out of meetings [09:49:54] i like bwalker's proposal - i think we could even leave out the ioat utilities for 18.10 [09:50:11] that's my 0.02 cents [09:50:24] I'm going to attempt to capture this in Trello under existing cards we have in the packaging board. [09:50:36] lhodev - does that work for your needs? [09:51:27] I think so. As a result, I think we should dispense entirely with the 'spdk-examples' package until 19.01. [09:52:00] perf and identify would appear in the base spdk package as apps alongside with spdk_tgt. [09:52:15] albeit prepended with "spdk_nvme_" [09:53:54] lhodev: +2 [09:55:57] +2 [09:56:55] Thanks much guys. I've updated a couple Trello cards correspondingly. [09:57:22] Now, back to the python issue. The spdk-tools package has a Requires dependency on python3. (groan) [09:58:36] To date, I'm only a dabbler in python. We (Oracle Linux) do not ship python3 even in our latest OL7.x version. [09:58:50] do the tools actually require python3 or are they python2 compatible? [09:59:26] One can retrieve python34 or python36 from Fedora's EPEL repo for use on OL, but they do not appear to do a "provides: python3" and hence the package installation fails. [09:59:35] https://pythonclock.org/ [10:00:10] bwalker: Based on my sniffing through some SPDK python code and googling "differences between python2 and python3", it appears to me that we do have some python3-specific constructs. [10:00:51] can you list one of these scripts? We can just try to run it and see [10:00:58] For example, the 'try/error' construct in python3 has a keyword 'as' in it. [10:02:22] Make that 'try/except' -- not 'try/error' [10:02:47] e.g.: scripts/spdkcli/ui_node.py [10:03:53] python3 uses parentheses for the print function, where has python2 does not. [10:04:03] whereas [10:05:08] But, it looks like python2 may allow parentheses for print, so we may be ok there. python3 requires parentheses for print. [10:53:17] lhodev: This is only a problem for the spdk-tools package, right? [10:53:39] what's in the spdk tools package today? just spdkcli? [10:53:46] bwalker: Correct. spdkcli and spdkrpc [10:54:06] ugh now I'm wondering if nvme perf/identify should be in spdktools instead [10:54:11] but regardless [10:54:19] spdkcli seems to be a python3 thing [10:54:51] pwodkowx said that he thought we should be compatible with python2. However, the rpm spec file on which we're working has a Requires python3 dependency explicitly called out. [10:55:08] is there a way to say requires "python 2 or python 3"? [10:55:49] We could in theory, I think, just specify "python" if it's truly all python2 compatible. [10:56:21] worth a shot, and one of the authors could confirm [10:57:41] The spec file also allows you to specify versions via operators like =, >, <, and so forth. However, what's confusing is that instead of doing that, there's a dependency on 'python3' by name. I don't grok how this is typically handled with other packages. [10:59:29] we should probably say python 2.7 or greater [11:00:32] Looking in https://trello.com/c/mrasr8mc, pwodkowx appears to have greater insight into this. [11:01:02] Under his TODO: list therein, he had marked as completed "replace python with python3 -> need patch for SPDK". [11:30:19] *** Joins: travis-ci (~travis-ci@ec2-54-92-131-6.compute-1.amazonaws.com) [11:30:20] (spdk/master) log: update tracelog usage message (Liang Yan) [11:30:20] Diff URL: https://github.com/spdk/spdk/compare/f26b1fca5f14...b1b3d39eaa96 [11:30:20] *** Parts: travis-ci (~travis-ci@ec2-54-92-131-6.compute-1.amazonaws.com) () [11:39:50] *** Joins: lhodev_ (~lhodev@inet-hqmc03-o.oracle.com) [11:48:51] *** Quits: lhodev (~lhodev@66-90-218-190.dyn.grandenetworks.net) (*.net *.split) [11:48:51] *** Quits: fionatrahe (~fionatrah@134.134.139.72) (*.net *.split) [11:48:52] *** Quits: KipIngram (~kipingram@185.149.90.58) (*.net *.split) [11:48:52] *** Quits: pniedzwx (pniedzwx@nat/intel/x-pqawdrfuuqzjyzez) (*.net *.split) [11:48:52] *** Quits: peluse (~peluse@134.134.139.72) (*.net *.split) [12:26:46] *** Quits: lhodev_ (~lhodev@inet-hqmc03-o.oracle.com) (Quit: Textual IRC Client: www.textualapp.com) [12:28:22] *** Joins: lhodev (~lhodev@inet-hqmc03-o.oracle.com) [13:36:22] I attempted to respond to a recent'ish email on the SPDK mailing list, and got bounced with a "The message's content type was not explicitly allowed." Never ran into this before. [13:37:01] Inspection of the outgoing mail's header shows: "Content-Type: multipart/related; type="multipart/alternative"; [13:38:19] which e-mail did you respond to? [13:38:48] we can check on the mailing list admin site for any additional info on why it failed [13:40:08] I attempted to respond to quzhouhui's [CASS SPAM]Re: spdk exits with failure if hugemem is very large [13:40:23] wuzhouhui [13:41:55] His email's header's Content-Type specified text/plan; charset="utf-8" [13:42:29] I thought my (Mac's) mail client generally attempted to format replies using the same content-type. At least I thought I remember reading that somewhere... [13:43:58] I meant to write "text/plain" -- not "text/plan". Sorry for the typo. [13:44:22] *** Joins: bwalker_ (~bwalker@ip70-190-226-244.ph.ph.cox.net) [13:44:23] *** ChanServ sets mode: +o bwalker_ [13:53:56] I just re-sent, ensuring I marked the message plain text first. Will see how it goes. [13:55:44] Looks like that worked fine. [13:58:06] cool [15:03:20] *** Quits: bwalker_ (~bwalker@ip70-190-226-244.ph.ph.cox.net) (Quit: Leaving) [15:25:42] bwalker: ping [15:32:37] *** Joins: bwalker_ (~bwalker@ip70-190-226-244.ph.ph.cox.net) [15:32:37] *** ChanServ sets mode: +o bwalker_ [15:45:52] *** Joins: pniedzwx_ (~pniedzwx_@89-77-161-93.dynamic.chello.pl) [15:46:51] *** Quits: pniedzwx_ (~pniedzwx_@89-77-161-93.dynamic.chello.pl) (Client Quit) [16:28:30] *** Joins: johnmeneghini (~johnmeneg@pool-108-20-29-249.bstnma.fios.verizon.net) [16:29:34] merged [16:30:27] can you rebase your rdma series? [16:30:33] yep [16:33:14] *** Joins: travis-ci (~travis-ci@ec2-54-144-80-50.compute-1.amazonaws.com) [16:33:15] (spdk/master) test/bdev: change crypto device conf based on environment (Seth Howell) [16:33:15] Diff URL: https://github.com/spdk/spdk/compare/b1b3d39eaa96...33df76dc93e4 [16:33:15] *** Parts: travis-ci (~travis-ci@ec2-54-144-80-50.compute-1.amazonaws.com) () [16:34:32] it's rebased [16:34:39] unfortunately, it's going to fail on the soft roce systems [16:34:45] because of the soft roce bug [16:34:55] but I'm curious to see if it passes on real hardware now [16:58:23] *** Quits: johnmeneghini (~johnmeneg@pool-108-20-29-249.bstnma.fios.verizon.net) (Quit: Leaving.) [21:01:15] did it cancel our meeting series again [21:01:26] yeah - i thought paul set up a new one but i don't see it [21:01:30] 599 326 212 [21:01:36] i just set up one for tonight [21:01:46] same password as usual [21:28:02] *** Joins: travis-ci (~travis-ci@ec2-54-80-44-47.compute-1.amazonaws.com) [21:28:03] (spdk/master) env: use dynamic memory management for DPDK 18.05.1+ (Darek Stojaczyk) [21:28:04] Diff URL: https://github.com/spdk/spdk/compare/33df76dc93e4...2d718da0438c [21:28:04] *** Parts: travis-ci (~travis-ci@ec2-54-80-44-47.compute-1.amazonaws.com) () [21:45:19] *** Quits: lhodev (~lhodev@inet-hqmc03-o.oracle.com) (Remote host closed the connection) [21:46:00] *** Joins: lhodev (~lhodev@66-90-218-190.dyn.grandenetworks.net) [22:13:35] *** Joins: sidspdk (10f2ea16@gateway/web/freenode/ip.16.242.234.22) [22:30:12] *** Quits: bwalker_ (~bwalker@ip70-190-226-244.ph.ph.cox.net) (Quit: Leaving) [23:12:39] *** Quits: sidspdk (10f2ea16@gateway/web/freenode/ip.16.242.234.22) (Ping timeout: 256 seconds)