Hi Shahar,
The target branch for the push should be ‘refs/for/master’, not ‘master’ – if you configured a remote as specified in
http://www.spdk.io/development/ it should look like:
[remote "review"]
url = https://review.gerrithub.io/spdk/spdk
push = HEAD:refs/for/master
Hi Ben,
I have the code ready for review (spdk/master on dpdk/18.02), but I do not have push rights for gerrithub:
shahar.salzman@shahars-vm:~/Kaminario/git/spdk$ git push spdk-review HEAD:master
Password for 'https://ShaharSalzman-K@review.gerrithub.io':
Counting objects: 109, done.
Compressing objects: 100% (22/22), done.
Writing objects: 100% (22/22), 8.70 KiB | 0 bytes/s, done.
Total 22 (delta 14), reused 0 (delta 0)
remote: Resolving deltas: 100% (14/14)
remote: Branch refs/heads/master:
remote: You are not allowed to perform this operation.
remote: To push into this reference you need 'Push' rights.
remote: User: ShaharSalzman-K
remote: Please read the documentation and contact an administrator
remote: if you feel the configuration is incorrect
remote: Processing changes: refs: 1, done
! [remote rejected] HEAD -> master (prohibited by Gerrit: ref update access denied)
error: failed to push some refs to 'https://ShaharSalzman-K@review.gerrithub.io/a/spdk/spdk'
Am I doing something incorrect, or is this just a permission issue?
Thanks,
Shahar
From: SPDK <spdk-bounces@lists.01.org>
on behalf of Shahar Salzman <shahar.salzman@kaminario.com>
Sent: Wednesday, April 25, 2018 9:02:38 AM
To: Storage Performance Development Kit
Subject: Re: [SPDK] SPDK + user space appliance
Hi Ben,
The code is currently working on v17.07, we are planning on bumping the version to one of the latest stable versions (18.01?) + master.
It will take me (hopefully) a few days to update the code and have our internal CI start running on this version, not sure it would be useful, but I can get our working 17.07 code (+ reference application)
for review much faster.
What is the best course of action?
Shahar
From: SPDK <spdk-bounces@lists.01.org>
on behalf of Walker, Benjamin <benjamin.walker@intel.com>
Sent: Tuesday, April 24, 2018 7:19:12 PM
To: Storage Performance Development Kit
Subject: Re: [SPDK] SPDK + user space appliance
Hi Shahar,
Would you be willing to submit your bdev module as a patch on GerritHub? That way everyone can take a look and provide feedback. If you don’t want it to run
the tests, you can put [RFC] and the beginning of the commit message.
Thanks,
Ben
From: SPDK [mailto:spdk-bounces@lists.01.org]
On Behalf Of Shahar Salzman
Sent: Monday, April 23, 2018 8:45 AM
To: spdk@lists.01.org
Subject: Re: [SPDK] SPDK + user space appliance
Hi Ben,
Bumping this thread since I've been having some new thoughts on the issue now that we are starting integration with newer spdk versions.
Unfortunately the merge isn't as smooth as I'd like it to be since the bdev module is pretty tightly integrated into spdk, perhaps we made some false assumptions writing the module, but it seems
some of the newer spdk features are complicating the integration.
My question is, if this passthrough module is useful, wouldn't it be better to maintain it as part of spdk so that we can catch issues as soon as they show up?
We would be happy to help with maintaining this module, the module with is currently part of our CI with our "frozen" spdk version, but once integrated into the newer version we choose, I'll add
it to the CI our CI as well.
Shahar
From: SPDK <spdk-bounces@lists.01.org>
on behalf of Walker, Benjamin <benjamin.walker@intel.com>
Sent: Friday, February 2, 2018 11:43:58 PM
To: spdk@lists.01.org
Subject: Re: [SPDK] SPDK + user space appliance
On Thu, 2018-02-01 at 08:29 +0000, Shahar Salzman wrote:
> Hi Ben,
>
> Would you also like to take a look at the bdev_user module?
> It still needs some patching (as some of the stuff is still hard coded), but I
> think we can get most of it cleaned up in a couple of days.
>
> In any case, is it the intention that the user write his own bdev module, or
> would this user appliance glue be a useful generic module?
For existing storage stacks that serve block I/O, like the internals of a SAN,
the idea is that you write your own bdev module to forward I/O coming out of the
SPDK bdev layer. Then you can use the SPDK iSCSI/NVMe-oF/vhost targets mostly
as-is.
In some cases, the actual iSCSI/NVMe-oF/vhost target applications won't
integrate nicely directly into an existing storage application because they
spawn their own threads and allocate their own memory. To support that, the
libraries may be consumed directly instead of the applications (lib/iscsi,
lib/scsi, lib/nvmf, etc.). The libraries don't spawn any of their own threads,
but instead rely on SPDK's abstractions in include/spdk/io_channel.h. See
http://www.spdk.io/doc/concurrency.html
We don't currently have a way to write a custom bdev module that resides outside
of the SPDK source tree, but it's very possible to add support for that. But
beyond that inconvenience (just drop your module in lib/bdev for now), writing a
bdev module is the recommended way of interacting with the bottom end of the
SPDK bdev layer. I think that's what you really want to be doing in your code,
from what I can tell.
I hope that helps!
_______________________________________________
SPDK mailing list
SPDK@lists.01.org
https://lists.01.org/mailman/listinfo/spdk