[SPDK] Analysis of SPDK-originated patches to DPDK fork spdk-18.08

[SPDK] Analysis of SPDK-originated patches to DPDK fork spdk-18.08

[Lance Hartmann ORACLE]

[-- Attachment #1: Type: text/plain, Size: 2827 bytes --]



I've put together a spreadsheet (attached) and a PDF as well for folks who'd rather not open Excel attachments.

The point of this exercise was to identify the SPDK-originated patches to the SPDK's fork of the DPDK (branch spdk-18.08), and then attempt to determine whether:

	• they had been accepted in upstream DPDK 18.11
	• they were cherry-pick'd forward to SPDK's fork of DPDK (branch spdk-18.11)
	• they've appeared in upstream DPDK-stable as of tag v18.08.1-rc3
	• they've appeared in upstream DPDK-stable as of tag v18.11.1-rc1
	• they've appeared in upstream DPDK-stable as of tag v19.02-rc1

I had hoped that I might be able to build SPDK 18.10.1 against the forthcoming, pure upstream DPDK v18.08.1, but then after the email exchange with Jim who had forwarded email from Bruce Richardson and Ferruh Yigit, I was prompted to consider building against pure upstream DPDK v18.11 (or forthcoming pure upstream DPDK v18.11.1).

However, in any of those cases, it appears the following SPDK-originated patches to SPDK's fork of DPDK branch spdk-18.08 have not been promoted to any of the upstream DPDK branches/tags, but instead only carried as cherry-pick's to our fork of DPDK branch spdk-18.11 (or apparently nowhere further at all) so I'd like to understand the deeper ramifications of them so that I may decide whether to include them as rpm patches to a custom DPDK build.   For some I'm fairly certain I can ignore as they're either crypto or BSD-related, but some of them I've marked as "unknown ???" because I don't know what I should do about them.

fork DPDK branch spdk-18.08 hash (description)
======================================
fbde197 (dpdk: temp hacks to enable SPDK crypto vbdev)
- Planning to ignore this as I will configure/build SPDK 18.10.1 without crypto enabled.

895f630 (Revert "contigmem: do not zero pages during each mmap")
- Planning to ignore as this is only related to BSD.

4275b1a (RHEL 6.4 support - use previous 'deprecated' attibute API)
- unknown ???

4c617c2 (memory: implement "single file segments" for legacy mem mode)
- unknown ???

632bbe7 (vfio: don't map single-segment hugepage memory in legacy mem mode)
- unknown ???

812c579 (Revert "crypto/aesni_mb: call buffer manager allocation")
- Planning to ignore this as I will configure/build SPDK 18.10.1 without crypto enabled.

73fadf0 (crypto: allow memzone to be created from secondary process)
- Planning to ignore this as I will configure/build SPDK 18.10.1 without crypto enabled.

96fae0e (pci_common_uio: store the pci dev address in secondary processes)
- Planning to ignore this as I will configure/build SPDK 18.10.1 without crypto enabled.   Issue for QAT cards when using crypto drivers.



thanks,

--
Lance Hartmann
lance.hartmann(a)oracle.com

Re: [SPDK] Analysis of SPDK-originated patches to DPDK fork spdk-18.08

[Lance Hartmann ORACLE]

[-- Attachment #1: Type: text/plain, Size: 5510 bytes --]



Many thanks for shedding light on those "unknown" (to me) patches Darek.   That's a big help!

I think I'll build a DPDK based on either the forthcoming v18.11.1 if it is released soon, or possibly a custom v18.11 with the addition of the patch da7bee1 (malloc: notify primary process about hotplug in secondary).  I lean more toward some flavor of v18.11 since that's an LTS release, plus it seems that 70d3625 (bus/pci: fix unexpected resource mapping override) was not backport'd to DPDK v18.08.1; at least, I didn't see it in dpdk-stable v18.08.1-rc3.   That one *is* in v18.11.

During our last call, I think someone (Ben?) mentioned building an SPDK v18.10 (or preferably v18.10.1) against DPDK v18.11.   I'd really like to see that run through the test pool to gain greater confidence that it works well.

cheers,

--
Lance Hartmann
lance.hartmann(a)oracle.com


> On Mar 6, 2019, at 1:10 AM, Stojaczyk, Dariusz <dariusz.stojaczyk(a)intel.com> wrote:
> 
> Lance, it's safe to ignore those patches. Please see below.
> 
>> -----Original Message-----
>> From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Lance
>> Hartmann ORACLE
>> Sent: Tuesday, March 5, 2019 10:16 PM
>> To: Storage Performance Development Kit <spdk(a)lists.01.org>
>> Subject: [SPDK] Analysis of SPDK-originated patches to DPDK fork spdk-18.08
>> 
>> 
>> 
>> I've put together a spreadsheet (attached) and a PDF as well for folks who'd
>> rather not open Excel attachments.
>> 
>> The point of this exercise was to identify the SPDK-originated patches to the
>> SPDK's fork of the DPDK (branch spdk-18.08), and then attempt to determine
>> whether:
>> 
>> 	• they had been accepted in upstream DPDK 18.11
>> 	• they were cherry-pick'd forward to SPDK's fork of DPDK (branch
>> spdk-18.11)
>> 	• they've appeared in upstream DPDK-stable as of tag v18.08.1-rc3
>> 	• they've appeared in upstream DPDK-stable as of tag v18.11.1-rc1
>> 	• they've appeared in upstream DPDK-stable as of tag v19.02-rc1
>> 
>> I had hoped that I might be able to build SPDK 18.10.1 against the
>> forthcoming, pure upstream DPDK v18.08.1, but then after the email
>> exchange with Jim who had forwarded email from Bruce Richardson and
>> Ferruh Yigit, I was prompted to consider building against pure upstream
>> DPDK v18.11 (or forthcoming pure upstream DPDK v18.11.1).
>> 
>> However, in any of those cases, it appears the following SPDK-originated
>> patches to SPDK's fork of DPDK branch spdk-18.08 have not been promoted
>> to any of the upstream DPDK branches/tags, but instead only carried as
>> cherry-pick's to our fork of DPDK branch spdk-18.11 (or apparently nowhere
>> further at all) so I'd like to understand the deeper ramifications of them so
>> that I may decide whether to include them as rpm patches to a custom DPDK
>> build.   For some I'm fairly certain I can ignore as they're either crypto or BSD-
>> related, but some of them I've marked as "unknown ???" because I don't
>> know what I should do about them.
>> 
>> fork DPDK branch spdk-18.08 hash (description)
>> ======================================
>> fbde197 (dpdk: temp hacks to enable SPDK crypto vbdev)
>> - Planning to ignore this as I will configure/build SPDK 18.10.1 without crypto
>> enabled.
>> 
>> 895f630 (Revert "contigmem: do not zero pages during each mmap")
>> - Planning to ignore as this is only related to BSD.
>> 
>> 4275b1a (RHEL 6.4 support - use previous 'deprecated' attibute API)
>> - unknown ???
> 
> This is a small fix for old and unsupported gcc versions (present in RHEL6.4 and CentOS 6), which otherwise fail to build DPDK. It's not required for packaging. 
> 
>> 
>> 4c617c2 (memory: implement "single file segments" for legacy mem mode)
>> - unknown ???
>> 
> 
> This is a feature for DPDK legacy memory management, which SPDK does not use anymore. Initially SPDK was not capable of running with DPDK dynamic memory management so it was forced to use '--legacy-mem'  DPDK param. We fixed SPDK and now use dynamic memory management unconditionally, leaving this patch obsolete.
> 
> The patch itself was enabling SPDK vhost-user PMD to work with 2MB hugepages, but that's supported by default in the dynamic memory management mode.
> 
>> 632bbe7 (vfio: don't map single-segment hugepage memory in legacy mem
>> mode)
>> - unknown ???
> 
> It's a bugfix for the patch above. It's safe to leave it out.
> 
>> 
>> 812c579 (Revert "crypto/aesni_mb: call buffer manager allocation")
>> - Planning to ignore this as I will configure/build SPDK 18.10.1 without crypto
>> enabled.
>> 
>> 73fadf0 (crypto: allow memzone to be created from secondary process)
>> - Planning to ignore this as I will configure/build SPDK 18.10.1 without crypto
>> enabled.
>> 
>> 96fae0e (pci_common_uio: store the pci dev address in secondary
>> processes)
>> - Planning to ignore this as I will configure/build SPDK 18.10.1 without crypto
>> enabled.   Issue for QAT cards when using crypto drivers.
>> 
> 
> Ack. Those are not needed for packaged SPDK.
> 
> D. 
> 
>> 
>> 
>> thanks,
>> 
>> --
>> Lance Hartmann
>> lance.hartmann(a)oracle.com
>> 
>> _______________________________________________
>> SPDK mailing list
>> SPDK(a)lists.01.org
>> https://lists.01.org/mailman/listinfo/spdk
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk

Re: [SPDK] Analysis of SPDK-originated patches to DPDK fork spdk-18.08

[Stojaczyk, Dariusz]

[-- Attachment #1: Type: text/plain, Size: 4268 bytes --]

Lance, it's safe to ignore those patches. Please see below.

> -----Original Message-----
> From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Lance
> Hartmann ORACLE
> Sent: Tuesday, March 5, 2019 10:16 PM
> To: Storage Performance Development Kit <spdk(a)lists.01.org>
> Subject: [SPDK] Analysis of SPDK-originated patches to DPDK fork spdk-18.08
> 
> 
> 
> I've put together a spreadsheet (attached) and a PDF as well for folks who'd
> rather not open Excel attachments.
> 
> The point of this exercise was to identify the SPDK-originated patches to the
> SPDK's fork of the DPDK (branch spdk-18.08), and then attempt to determine
> whether:
> 
> 	• they had been accepted in upstream DPDK 18.11
> 	• they were cherry-pick'd forward to SPDK's fork of DPDK (branch
> spdk-18.11)
> 	• they've appeared in upstream DPDK-stable as of tag v18.08.1-rc3
> 	• they've appeared in upstream DPDK-stable as of tag v18.11.1-rc1
> 	• they've appeared in upstream DPDK-stable as of tag v19.02-rc1
> 
> I had hoped that I might be able to build SPDK 18.10.1 against the
> forthcoming, pure upstream DPDK v18.08.1, but then after the email
> exchange with Jim who had forwarded email from Bruce Richardson and
> Ferruh Yigit, I was prompted to consider building against pure upstream
> DPDK v18.11 (or forthcoming pure upstream DPDK v18.11.1).
> 
> However, in any of those cases, it appears the following SPDK-originated
> patches to SPDK's fork of DPDK branch spdk-18.08 have not been promoted
> to any of the upstream DPDK branches/tags, but instead only carried as
> cherry-pick's to our fork of DPDK branch spdk-18.11 (or apparently nowhere
> further at all) so I'd like to understand the deeper ramifications of them so
> that I may decide whether to include them as rpm patches to a custom DPDK
> build.   For some I'm fairly certain I can ignore as they're either crypto or BSD-
> related, but some of them I've marked as "unknown ???" because I don't
> know what I should do about them.
> 
> fork DPDK branch spdk-18.08 hash (description)
> ======================================
> fbde197 (dpdk: temp hacks to enable SPDK crypto vbdev)
> - Planning to ignore this as I will configure/build SPDK 18.10.1 without crypto
> enabled.
> 
> 895f630 (Revert "contigmem: do not zero pages during each mmap")
> - Planning to ignore as this is only related to BSD.
> 
> 4275b1a (RHEL 6.4 support - use previous 'deprecated' attibute API)
> - unknown ???

This is a small fix for old and unsupported gcc versions (present in RHEL6.4 and CentOS 6), which otherwise fail to build DPDK. It's not required for packaging. 

> 
> 4c617c2 (memory: implement "single file segments" for legacy mem mode)
> - unknown ???
> 

This is a feature for DPDK legacy memory management, which SPDK does not use anymore. Initially SPDK was not capable of running with DPDK dynamic memory management so it was forced to use '--legacy-mem'  DPDK param. We fixed SPDK and now use dynamic memory management unconditionally, leaving this patch obsolete.

The patch itself was enabling SPDK vhost-user PMD to work with 2MB hugepages, but that's supported by default in the dynamic memory management mode.

> 632bbe7 (vfio: don't map single-segment hugepage memory in legacy mem
> mode)
> - unknown ???

It's a bugfix for the patch above. It's safe to leave it out.

> 
> 812c579 (Revert "crypto/aesni_mb: call buffer manager allocation")
> - Planning to ignore this as I will configure/build SPDK 18.10.1 without crypto
> enabled.
> 
> 73fadf0 (crypto: allow memzone to be created from secondary process)
> - Planning to ignore this as I will configure/build SPDK 18.10.1 without crypto
> enabled.
> 
> 96fae0e (pci_common_uio: store the pci dev address in secondary
> processes)
> - Planning to ignore this as I will configure/build SPDK 18.10.1 without crypto
> enabled.   Issue for QAT cards when using crypto drivers.
> 

Ack. Those are not needed for packaged SPDK.

D. 

> 
> 
> thanks,
> 
> --
> Lance Hartmann
> lance.hartmann(a)oracle.com
> 
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk

Re: [SPDK] Analysis of SPDK-originated patches to DPDK fork spdk-18.08

[Lance Hartmann ORACLE]

[-- Attachment #1: Type: text/plain, Size: 3496 bytes --]



Apparently, the attachments were detached.   Was unsure how that might work (or not) on the list.

Regardless, the particular commits about which I'm seeking input are listed in the original email.   If anyone would like the Excel spreadsheet or PDF, please let me know and we'll figure out another way to send them.

thanks,

--
Lance Hartmann



> On Mar 5, 2019, at 3:16 PM, Lance Hartmann ORACLE <lance.hartmann(a)oracle.com> wrote:
> 
> 
> 
> I've put together a spreadsheet (attached) and a PDF as well for folks who'd rather not open Excel attachments.
> 
> The point of this exercise was to identify the SPDK-originated patches to the SPDK's fork of the DPDK (branch spdk-18.08), and then attempt to determine whether:
> 
> 	• they had been accepted in upstream DPDK 18.11
> 	• they were cherry-pick'd forward to SPDK's fork of DPDK (branch spdk-18.11)
> 	• they've appeared in upstream DPDK-stable as of tag v18.08.1-rc3
> 	• they've appeared in upstream DPDK-stable as of tag v18.11.1-rc1
> 	• they've appeared in upstream DPDK-stable as of tag v19.02-rc1
> 
> I had hoped that I might be able to build SPDK 18.10.1 against the forthcoming, pure upstream DPDK v18.08.1, but then after the email exchange with Jim who had forwarded email from Bruce Richardson and Ferruh Yigit, I was prompted to consider building against pure upstream DPDK v18.11 (or forthcoming pure upstream DPDK v18.11.1).
> 
> However, in any of those cases, it appears the following SPDK-originated patches to SPDK's fork of DPDK branch spdk-18.08 have not been promoted to any of the upstream DPDK branches/tags, but instead only carried as cherry-pick's to our fork of DPDK branch spdk-18.11 (or apparently nowhere further at all) so I'd like to understand the deeper ramifications of them so that I may decide whether to include them as rpm patches to a custom DPDK build.   For some I'm fairly certain I can ignore as they're either crypto or BSD-related, but some of them I've marked as "unknown ???" because I don't know what I should do about them.
> 
> fork DPDK branch spdk-18.08 hash (description)
> ======================================
> fbde197 (dpdk: temp hacks to enable SPDK crypto vbdev)
> - Planning to ignore this as I will configure/build SPDK 18.10.1 without crypto enabled.
> 
> 895f630 (Revert "contigmem: do not zero pages during each mmap")
> - Planning to ignore as this is only related to BSD.
> 
> 4275b1a (RHEL 6.4 support - use previous 'deprecated' attibute API)
> - unknown ???
> 
> 4c617c2 (memory: implement "single file segments" for legacy mem mode)
> - unknown ???
> 
> 632bbe7 (vfio: don't map single-segment hugepage memory in legacy mem mode)
> - unknown ???
> 
> 812c579 (Revert "crypto/aesni_mb: call buffer manager allocation")
> - Planning to ignore this as I will configure/build SPDK 18.10.1 without crypto enabled.
> 
> 73fadf0 (crypto: allow memzone to be created from secondary process)
> - Planning to ignore this as I will configure/build SPDK 18.10.1 without crypto enabled.
> 
> 96fae0e (pci_common_uio: store the pci dev address in secondary processes)
> - Planning to ignore this as I will configure/build SPDK 18.10.1 without crypto enabled.   Issue for QAT cards when using crypto drivers.
> 
> 
> 
> thanks,
> 
> --
> Lance Hartmann
> 
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk