Copy framework rename
by Luse, Paul E
Hi Everyone,
For 20.04 we’re going to start expanding the capabilities of the existing copy framework. Actually, today it already does copy and memfill so the name “copy” isn’t really the best but when we add dif/dix and crc it will be even less accurate.
If you have input on the new naming, please provide it via reviewing the patch below. It’s a bit more than just search/replace but only in a few of the files, most files it’s just replace ‘copy’ with ‘accel’ so don’t be afraid of the large number of files ☺
https://review.spdk.io/gerrit/c/spdk/spdk/+/576
global: rename copy to accel
The copy engine library, modules and public APIs have been renamed.
Use of the word `copy` has been replaced with the word `accel`
short for accelerator in preparation for adding new capabilities
in the future. Additionally, APIs for what was previously called
the `memcpy` engine have been renamed to identify the engine as a
software accelerator.
Thanks
Paul
1 year, 1 month
New Gerrit Instance
by Howell, Seth
Hi all,
With a successful 20.01 release behind us, we are excited to announce a change to the SPDK CI system that will help our project remain independent, and ensure the reliability of the CI infrastructure. We are migrating our review services from review.gerrithub.io to a new, community hosted domain, review.spdk.io.
What does this mean for you as a developer?
The change to your day to day operations should be small. The initial work is also quite simple:
1. Navigate to review.spdk.io and login using the login button in the top right. We use GitHub OAUTH the same as review.gerrithub.io
2. Upload any public ssh keys you use to upload to GerritHub to the new site under the settings tab and generate an https password if desired. The https://spdk.io/development/#gerrithub guide can be useful here as the steps are the same.
3. All of the repositories in review.spdk.io have the same names as their review.spdk.io equivalents, and all of the refs/for paths are equivalent. This means that you can simply go into your existing local spdk/* GitHub repositories, update all remote references from review.gerrithub.io to review.spdk.io in your .git/config file and continue using the same repository for review.spdk.io
4. As of tomorrow, all of your open changes will need to be re-uploaded to review.spdk.io. If you performed step 3, you can simply checkout the latest master, rebase your local branches on top of that, and push to the proper review branch (whatever names you have configured in your local .git/config file).
All of the spdk/* projects currently in review.gerrithub.io have been copied over to review.spdk.io so you should be able to resume development on any of those projects immediately after the switch. Karol Latecki and myself will both be available to answer questions in real time in the days following the transition on the SPDK Jenkins-ci and general slack channels.
All other features of Gerrit will remain the same. Links to logs will be posted automatically to the reviews as they complete, and -1 tags can be removed using the false positive reporting system. If you encounter any issues with review.spdk.io, please reach out on the SPDK slack channel.
Here's looking forward to a great 2020 and the continued growth of the SPDK development community!
Thank you,
Seth Howell
Summary: The new Gerrit server is located at review.spdk.io. Please migrate your patches to that server starting tomorrow.
1 year, 1 month
Re: vfio multiple processes
by Luse, Paul E
Excellent!
On 2/1/20, 7:06 AM, "Nabarro, Tom" <tom.nabarro(a)intel.com> wrote:
Resolved by adding pci whitelist into spdk_env_opts.
Adding whitelist into nvme.conf was not sufficient.
Regards,
Tom Nabarro - DCG/ESAD
M: +44 (0)7786 260986
Skype: tom.nabarro
From: Nabarro, Tom
Sent: Friday, January 31, 2020 12:42 PM
To: 'Storage Performance Development Kit' <spdk(a)lists.01.org>
Subject: vfio multiple processes
Can't run multiple SPDK processes each accessing disjoint set of NVMe drives using VFIO driver (even as root). Each process seems to try to access all /dev/vfio/* device files and get lots of resource busy messages. Sometimes one of the processes complaint it can't find the device it's been assigned in nvme.conf.
Have any ideas?
(processes are started in normal, non-multiprocess mode)
Thanks in advance
Best regards,
Tom Nabarro BEng (hons)
Extreme Storage Architecture & Development
Intel Corporation
E: tom.nabarro(a)intel.com<mailto:tom.nabarro@intel.com>
M: +44 (0)7786 260986
Skype: tom.nabarro
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
SPDK mailing list -- spdk(a)lists.01.org
To unsubscribe send an email to spdk-leave(a)lists.01.org
1 year, 1 month
