bus/pci: remove PCI bus from EAL

This function was previously private to the EAL layer. Other subsystems requires it, such as the PCI bus.

This function is only exposed for linuxapps.

In order not to force other components to include stdbool, which is incompatible with several NIC drivers, the return type has been changed from bool to int.

Signed-off-by Gaetan Rivet <[email protected]>

---
 lib/librte_eal/common/eal_private.h             | 11 -----
 lib/librte_eal/linuxapp/eal/Makefile            |  2 +
 lib/librte_eal/linuxapp/eal/eal_memory.c        |  3 +-
 lib/librte_eal/linuxapp/eal/eal_pci.c           |  1 +
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |  1 +
 lib/librte_eal/linuxapp/eal/rte_memory_linux.h  | 64 +++++++++++++++++++++++++
 6 files changed, 70 insertions(+), 12 deletions(-)
 create mode 100644 lib/librte_eal/linuxapp/eal/rte_memory_linux.h

lib/librte_eal/common/eal_private.h +0 -11

index 6d2206a..b7e4cc6 100644
@@ -327,17 +327,6 @@ int rte_eal_hugepage_init(void);
  */
 int rte_eal_hugepage_attach(void);
 
-/**
- * Returns true if the system is able to obtain
- * physical addresses. Return false if using DMA
- * addresses through an IOMMU.
- *
- * Drivers based on uio will not load unless physical
- * addresses are obtainable. It is only possible to get
- * physical addresses when running as a privileged user.
- */
-bool rte_eal_using_phys_addrs(void);
-
 /*
  * Validate a bus name.
  *

lib/librte_eal/linuxapp/eal/Makefile +2 -0

index 640afd0..530e286 100644
@@ -131,4 +131,6 @@ INC := rte_interrupts.h rte_kni_common.h rte_dom0_common.h
 SYMLINK-$(CONFIG_RTE_EXEC_ENV_LINUXAPP)-include/exec-env := \
        $(addprefix include/exec-env/,$(INC))
 
+SYMLINK-$(CONFIG_RTE_EXEC_ENV_LINUXAPP)-include += rte_memory_linux.h
+
 include $(RTE_SDK)/mk/rte.lib.mk

lib/librte_eal/linuxapp/eal/eal_memory.c +2 -1

index ebe0683..072bfe4 100644
@@ -99,6 +99,7 @@
 #include "eal_internal_cfg.h"
 #include "eal_filesystem.h"
 #include "eal_hugepages.h"
+#include "rte_memory_linux.h"
 
 #define PFN_MASK_SIZE  8
 

@@ -1472,7 +1473,7 @@ rte_eal_hugepage_attach(void)
        return -1;
 }
 
-bool
+int
 rte_eal_using_phys_addrs(void)
 {
        return phys_addrs_available;

lib/librte_eal/linuxapp/eal/eal_pci.c +1 -0

index 595622b..9d5b051 100644
@@ -45,6 +45,7 @@
 #include "eal_filesystem.h"
 #include "eal_private.h"
 #include "eal_pci_init.h"
+#include "rte_memory_linux.h"
 
 /**
  * @file

lib/librte_eal/linuxapp/eal/rte_eal_version.map +0 -0

index a5127d6..8916520 100644

lib/librte_eal/linuxapp/eal/rte_eal_version.map +0 -0

 } DPDK_17.05;

lib/librte_eal/linuxapp/eal/rte_memory_linux.h new file +64 -1

new file mode 100644
index 0000000..0400711
@@ -0,0 +1,64 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2017 6WIND S.A. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in
+ *       the documentation and/or other materials provided with the
+ *       distribution.
+ *     * Neither the name of 6WIND nor the names of its
+ *       contributors may be used to endorse or promote products derived
+ *       from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_MEMORY_LINUX_H_
+#define _RTE_MEMORY_LINUX_H_
+
+/**
+ * @file
+ *
+ * Memory-related Linux-specific RTE API.
+ */
+
+#include <rte_memory.h>
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * Drivers based on uio will not load unless physical
+ * addresses are obtainable. It is only possible to get
+ * physical addresses when running as a privileged user.
+ *
+ * @return
+ *   1 if the system is able to obtain physical addresses.
+ *   0 if using DMA addresses through an IOMMU.
+ */
+int rte_eal_using_phys_addrs(void);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_MEMORY_LINUX_H_ */
--

2.1.4

Quoted 91 lines · Gaetan Rivet

This function was previously private to the EAL layer. Other subsystems requires it, such as the PCI bus.

This function is only exposed for linuxapps.

In order not to force other components to include stdbool, which is incompatible with several NIC drivers, the return type has been changed from bool to int.

Signed-off-by Gaetan Rivet <[email protected]>

---
 lib/librte_eal/common/eal_private.h             | 11 -----
 lib/librte_eal/linuxapp/eal/Makefile            |  2 +
 lib/librte_eal/linuxapp/eal/eal_memory.c        |  3 +-
 lib/librte_eal/linuxapp/eal/eal_pci.c           |  1 +
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |  1 +
 lib/librte_eal/linuxapp/eal/rte_memory_linux.h  | 64 +++++++++++++++++++++++++
 6 files changed, 70 insertions(+), 12 deletions(-)
 create mode 100644 lib/librte_eal/linuxapp/eal/rte_memory_linux.h

lib/librte_eal/common/eal_private.h +0 -11

index 6d2206a..b7e4cc6 100644
@@ -327,17 +327,6 @@ int rte_eal_hugepage_init(void);
  */
 int rte_eal_hugepage_attach(void);
 
-/**
- * Returns true if the system is able to obtain
- * physical addresses. Return false if using DMA
- * addresses through an IOMMU.
- *
- * Drivers based on uio will not load unless physical
- * addresses are obtainable. It is only possible to get
- * physical addresses when running as a privileged user.
- */
-bool rte_eal_using_phys_addrs(void);
-
 /*
  * Validate a bus name.
  *

lib/librte_eal/linuxapp/eal/Makefile +2 -0

index 640afd0..530e286 100644
@@ -131,4 +131,6 @@ INC := rte_interrupts.h rte_kni_common.h rte_dom0_common.h
 SYMLINK-$(CONFIG_RTE_EXEC_ENV_LINUXAPP)-include/exec-env := \
        $(addprefix include/exec-env/,$(INC))
 
+SYMLINK-$(CONFIG_RTE_EXEC_ENV_LINUXAPP)-include += rte_memory_linux.h
+
 include $(RTE_SDK)/mk/rte.lib.mk

lib/librte_eal/linuxapp/eal/eal_memory.c +2 -1

index ebe0683..072bfe4 100644
@@ -99,6 +99,7 @@
 #include "eal_internal_cfg.h"
 #include "eal_filesystem.h"
 #include "eal_hugepages.h"
+#include "rte_memory_linux.h"
 
 #define PFN_MASK_SIZE  8
 

@@ -1472,7 +1473,7 @@ rte_eal_hugepage_attach(void)
        return -1;
 }
 
-bool
+int
 rte_eal_using_phys_addrs(void)
 {
        return phys_addrs_available;

lib/librte_eal/linuxapp/eal/eal_pci.c +1 -0

index 595622b..9d5b051 100644
@@ -45,6 +45,7 @@
 #include "eal_filesystem.h"
 #include "eal_private.h"
 #include "eal_pci_init.h"
+#include "rte_memory_linux.h"
 
 /**
  * @file

lib/librte_eal/linuxapp/eal/rte_eal_version.map +0 -0

index a5127d6..8916520 100644

lib/librte_eal/linuxapp/eal/rte_eal_version.map DPDK_17.08 { · line 210

Quoted 4 lines

lib/librte_eal/linuxapp/eal/rte_eal_version.map +1 -0

@@ -207,5 +207,6 @@ DPDK_17.08 {
 
        rte_bus_from_name;
        rte_bus_from_dev;
+       rte_eal_using_phys_addrs;  

Is this only for the UIO mapping? Would it be better to let UIO skip (and warn?) over RTE_BAD_PHYS_ADDR mappings? That way we don't need this export and its probably more resilient to bad mappings.

Thoughts? Olivier?

Hi,

Quoted 101 lines · Jan Blunck

Quoted 91 lines · Gaetan Rivet

This function was previously private to the EAL layer. Other subsystems requires it, such as the PCI bus.

This function is only exposed for linuxapps.

In order not to force other components to include stdbool, which is incompatible with several NIC drivers, the return type has been changed from bool to int.

Signed-off-by Gaetan Rivet <[email protected]>

---
 lib/librte_eal/common/eal_private.h             | 11 -----
 lib/librte_eal/linuxapp/eal/Makefile            |  2 +
 lib/librte_eal/linuxapp/eal/eal_memory.c        |  3 +-
 lib/librte_eal/linuxapp/eal/eal_pci.c           |  1 +
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |  1 +
 lib/librte_eal/linuxapp/eal/rte_memory_linux.h  | 64 +++++++++++++++++++++++++
 6 files changed, 70 insertions(+), 12 deletions(-)
 create mode 100644 lib/librte_eal/linuxapp/eal/rte_memory_linux.h

lib/librte_eal/common/eal_private.h +0 -11

index 6d2206a..b7e4cc6 100644
@@ -327,17 +327,6 @@ int rte_eal_hugepage_init(void);
  */
 int rte_eal_hugepage_attach(void);
 
-/**
- * Returns true if the system is able to obtain
- * physical addresses. Return false if using DMA
- * addresses through an IOMMU.
- *
- * Drivers based on uio will not load unless physical
- * addresses are obtainable. It is only possible to get
- * physical addresses when running as a privileged user.
- */
-bool rte_eal_using_phys_addrs(void);
-
 /*
  * Validate a bus name.
  *

lib/librte_eal/linuxapp/eal/Makefile +2 -0

index 640afd0..530e286 100644
@@ -131,4 +131,6 @@ INC := rte_interrupts.h rte_kni_common.h rte_dom0_common.h
 SYMLINK-$(CONFIG_RTE_EXEC_ENV_LINUXAPP)-include/exec-env := \
        $(addprefix include/exec-env/,$(INC))
 
+SYMLINK-$(CONFIG_RTE_EXEC_ENV_LINUXAPP)-include += rte_memory_linux.h
+
 include $(RTE_SDK)/mk/rte.lib.mk

lib/librte_eal/linuxapp/eal/eal_memory.c +2 -1

index ebe0683..072bfe4 100644
@@ -99,6 +99,7 @@
 #include "eal_internal_cfg.h"
 #include "eal_filesystem.h"
 #include "eal_hugepages.h"
+#include "rte_memory_linux.h"
 
 #define PFN_MASK_SIZE  8
 

@@ -1472,7 +1473,7 @@ rte_eal_hugepage_attach(void)
        return -1;
 }
 
-bool
+int
 rte_eal_using_phys_addrs(void)
 {
        return phys_addrs_available;

lib/librte_eal/linuxapp/eal/eal_pci.c +1 -0

index 595622b..9d5b051 100644
@@ -45,6 +45,7 @@
 #include "eal_filesystem.h"
 #include "eal_private.h"
 #include "eal_pci_init.h"
+#include "rte_memory_linux.h"
 
 /**
  * @file

lib/librte_eal/linuxapp/eal/rte_eal_version.map +0 -0

index a5127d6..8916520 100644

lib/librte_eal/linuxapp/eal/rte_eal_version.map DPDK_17.08 { · line 210

Quoted 4 lines

lib/librte_eal/linuxapp/eal/rte_eal_version.map +1 -0

@@ -207,5 +207,6 @@ DPDK_17.08 {
 
        rte_bus_from_name;
        rte_bus_from_dev;
+       rte_eal_using_phys_addrs;

Is this only for the UIO mapping? Would it be better to let UIO skip (and warn?) over RTE_BAD_PHYS_ADDR mappings? That way we don't need this export and its probably more resilient to bad mappings.

Quoted 1 line

Thoughts? Olivier?

From what I see, rte_eal_using_phys_addrs() is used by:

        rte_eal_pci_map_device(struct rte_pci_device *dev)
        {
                ...
                case RTE_KDRV_IGB_UIO:
                case RTE_KDRV_UIO_GENERIC:
                if (rte_eal_using_phys_addrs()) {
                        /* map resources for devices that use uio */
                        ret = pci_uio_map_resource(dev);
                }

Looking at pci_uio_map_resource() and its callees, I'm not sure it's easy to replace it something else. The functions that would return RTE_BAD_PHYS_ADDR (virt2phy-like) are not called there.

Quoted 119 lines · Olivier Matz

Hi,

Quoted 101 lines · Jan Blunck

Quoted 91 lines · Gaetan Rivet

This function was previously private to the EAL layer. Other subsystems requires it, such as the PCI bus.

This function is only exposed for linuxapps.

In order not to force other components to include stdbool, which is incompatible with several NIC drivers, the return type has been changed from bool to int.

Signed-off-by Gaetan Rivet <[email protected]>

---
 lib/librte_eal/common/eal_private.h             | 11 -----
 lib/librte_eal/linuxapp/eal/Makefile            |  2 +
 lib/librte_eal/linuxapp/eal/eal_memory.c        |  3 +-
 lib/librte_eal/linuxapp/eal/eal_pci.c           |  1 +
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |  1 +
 lib/librte_eal/linuxapp/eal/rte_memory_linux.h  | 64 +++++++++++++++++++++++++
 6 files changed, 70 insertions(+), 12 deletions(-)
 create mode 100644 lib/librte_eal/linuxapp/eal/rte_memory_linux.h

lib/librte_eal/common/eal_private.h +0 -11

index 6d2206a..b7e4cc6 100644
@@ -327,17 +327,6 @@ int rte_eal_hugepage_init(void);
  */
 int rte_eal_hugepage_attach(void);
 
-/**
- * Returns true if the system is able to obtain
- * physical addresses. Return false if using DMA
- * addresses through an IOMMU.
- *
- * Drivers based on uio will not load unless physical
- * addresses are obtainable. It is only possible to get
- * physical addresses when running as a privileged user.
- */
-bool rte_eal_using_phys_addrs(void);
-
 /*
  * Validate a bus name.
  *

lib/librte_eal/linuxapp/eal/Makefile +2 -0

index 640afd0..530e286 100644
@@ -131,4 +131,6 @@ INC := rte_interrupts.h rte_kni_common.h rte_dom0_common.h
 SYMLINK-$(CONFIG_RTE_EXEC_ENV_LINUXAPP)-include/exec-env := \
        $(addprefix include/exec-env/,$(INC))
 
+SYMLINK-$(CONFIG_RTE_EXEC_ENV_LINUXAPP)-include += rte_memory_linux.h
+
 include $(RTE_SDK)/mk/rte.lib.mk

lib/librte_eal/linuxapp/eal/eal_memory.c +2 -1

index ebe0683..072bfe4 100644
@@ -99,6 +99,7 @@
 #include "eal_internal_cfg.h"
 #include "eal_filesystem.h"
 #include "eal_hugepages.h"
+#include "rte_memory_linux.h"
 
 #define PFN_MASK_SIZE  8
 

@@ -1472,7 +1473,7 @@ rte_eal_hugepage_attach(void)
        return -1;
 }
 
-bool
+int
 rte_eal_using_phys_addrs(void)
 {
        return phys_addrs_available;

lib/librte_eal/linuxapp/eal/eal_pci.c +1 -0

index 595622b..9d5b051 100644
@@ -45,6 +45,7 @@
 #include "eal_filesystem.h"
 #include "eal_private.h"
 #include "eal_pci_init.h"
+#include "rte_memory_linux.h"
 
 /**
  * @file

lib/librte_eal/linuxapp/eal/rte_eal_version.map +0 -0

index a5127d6..8916520 100644

lib/librte_eal/linuxapp/eal/rte_eal_version.map DPDK_17.08 { · line 210

Quoted 4 lines

lib/librte_eal/linuxapp/eal/rte_eal_version.map +1 -0

@@ -207,5 +207,6 @@ DPDK_17.08 {
 
        rte_bus_from_name;
        rte_bus_from_dev;
+       rte_eal_using_phys_addrs;  

Is this only for the UIO mapping? Would it be better to let UIO skip (and warn?) over RTE_BAD_PHYS_ADDR mappings? That way we don't need this export and its probably more resilient to bad mappings.

Quoted 1 line

Thoughts? Olivier?

From what I see, rte_eal_using_phys_addrs() is used by:

        rte_eal_pci_map_device(struct rte_pci_device *dev)
        {
                ...
                case RTE_KDRV_IGB_UIO:
                case RTE_KDRV_UIO_GENERIC:
                if (rte_eal_using_phys_addrs()) {
                        /* map resources for devices that use uio */
                        ret = pci_uio_map_resource(dev);
                }

Quoted 4 lines

Looking at pci_uio_map_resource() and its callees, I'm not sure it's easy to replace it something else. The functions that would return RTE_BAD_PHYS_ADDR (virt2phy-like) are not called there.

Right, so why is it there in the first place? From what I can see the code should work just fine even in cases we don't have physical addresses available. Shouldn't the code actually requiring physical addresses (e.g. RX queue setup, ...) check for this instead?

-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of Gaetan Rivet
Sent: Thursday, June 08, 2017 12:59 AM
To: [email protected]
Cc: Gaetan Rivet
Subject: [dpdk-dev] [PATCH v2 06/12] cryptodev: disabled by default

Signed-off-by Gaetan Rivet <[email protected]>

---
 config/common_base | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

config/common_base +1 -2

index 0e0b732..cade611 100644
@@ -430,7 +430,7 @@ CONFIG_RTE_PMD_PACKET_PREFETCH=y
 #
 # Compile generic crypto device library
 #
-CONFIG_RTE_LIBRTE_CRYPTODEV=y
+CONFIG_RTE_LIBRTE_CRYPTODEV=n
 CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
 CONFIG_RTE_CRYPTO_MAX_DEVS=64
 CONFIG_RTE_CRYPTODEV_NAME_LEN=64
--

2.1.4

Quoted 24 lines

-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of Gaetan Rivet
Sent: Thursday, June 08, 2017 12:59 AM
To: [email protected]
Cc: Gaetan Rivet
Subject: [dpdk-dev] [PATCH v2 06/12] cryptodev: disabled by default

Signed-off-by Gaetan Rivet <[email protected]>

---
 config/common_base | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

config/common_base +1 -1

index 0e0b732..cade611 100644
@@ -430,7 +430,7 @@ CONFIG_RTE_PMD_PACKET_PREFETCH=y
 #
 # Compile generic crypto device library
 #
-CONFIG_RTE_LIBRTE_CRYPTODEV=y
+CONFIG_RTE_LIBRTE_CRYPTODEV=n

Quoted 5 lines

config/common_base +0 -1

 CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
 CONFIG_RTE_CRYPTO_MAX_DEVS=64
 CONFIG_RTE_CRYPTODEV_NAME_LEN=64
--

2.1.4

As already discussed, there should be no need to disable this, after applying this: http://dpdk.org/ml/archives/dev/2017-May/066382.html

-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of Gaetan Rivet
Sent: Thursday, June 8, 2017 12:59 AM
To: [email protected]
Cc: Gaetan Rivet <[email protected]>
Subject: [dpdk-dev] [PATCH v2 07/12] pdump: disabled by default

Signed-off-by Gaetan Rivet <[email protected]>

---
 config/common_base | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

config/common_base index renamed from config/common_base +0 -0

cade611..8ec5e4e 100644

config/common_base +0 -0

@@ -700,7 +700,7 @@ CONFIG_RTE_KNI_PREEMPT_DEFAULT=y  #  # Compile

the pdump library # -CONFIG_RTE_LIBRTE_PDUMP=y
+CONFIG_RTE_LIBRTE_PDUMP=n

#
# Compile vhost user library
--
2.1.4

Hi,

Quoted 20 lines

-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of Gaetan Rivet
Sent: Thursday, June 8, 2017 12:59 AM
To: [email protected]
Cc: Gaetan Rivet <[email protected]>
Subject: [dpdk-dev] [PATCH v2 07/12] pdump: disabled by default

Signed-off-by Gaetan Rivet <[email protected]>

---
 config/common_base | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

config/common_base index renamed from config/common_base +0 -0

cade611..8ec5e4e 100644

config/common_base +0 -0

@@ -700,7 +700,7 @@ CONFIG_RTE_KNI_PREEMPT_DEFAULT=y  #  # Compile

the pdump library # -CONFIG_RTE_LIBRTE_PDUMP=y
+CONFIG_RTE_LIBRTE_PDUMP=n

Quoted 4 lines

#
# Compile vhost user library
--
2.1.4

Since, you already mentioned in other mail to Ferruh that config flag disabling patches are only for testers compilation purpose and you have plans to make proper fix by end of June. I will wait on for actual patch.

Please see if rte_pci.h can be removed from the includes of rte_pdump.c , might be unnecessary include.

Thanks,
Reshma

Hi Reshma,

Quoted 22 lines · Reshma

Hi,

Quoted 20 lines

-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of Gaetan Rivet
Sent: Thursday, June 8, 2017 12:59 AM
To: [email protected]
Cc: Gaetan Rivet <[email protected]>
Subject: [dpdk-dev] [PATCH v2 07/12] pdump: disabled by default

Signed-off-by Gaetan Rivet <[email protected]>

---
 config/common_base | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

config/common_base index renamed from config/common_base +0 -0

cade611..8ec5e4e 100644

config/common_base +0 -0

@@ -700,7 +700,7 @@ CONFIG_RTE_KNI_PREEMPT_DEFAULT=y  #  # Compile

the pdump library # -CONFIG_RTE_LIBRTE_PDUMP=y
+CONFIG_RTE_LIBRTE_PDUMP=n

Quoted 7 lines

Quoted 4 lines

#
# Compile vhost user library
--
2.1.4

Since, you already mentioned in other mail to Ferruh that config flag disabling patches are only for testers compilation purpose and you have plans to make proper fix by end of June. I will wait on for actual patch.

I said I planned to do so, but found out that I would not have enough time before the end of June. Sorry about the ambiguous phrasing.

Do you think you will be able to fix this library in time?

Quoted 5 lines

Please see if rte_pci.h can be removed from the includes of rte_pdump.c , might be unnecessary include.

Thanks,
Reshma

Quoted 33 lines · Gaëtan Rivet

Hi Reshma,

Quoted 22 lines · Reshma

Hi,

Quoted 20 lines

-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of Gaetan Rivet
Sent: Thursday, June 8, 2017 12:59 AM
To: [email protected]
Cc: Gaetan Rivet <[email protected]>
Subject: [dpdk-dev] [PATCH v2 07/12] pdump: disabled by default

Signed-off-by Gaetan Rivet <[email protected]>

---
 config/common_base | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

config/common_base index renamed from config/common_base +0 -0

cade611..8ec5e4e 100644

config/common_base +0 -0

@@ -700,7 +700,7 @@ CONFIG_RTE_KNI_PREEMPT_DEFAULT=y  #  # Compile

the pdump library # -CONFIG_RTE_LIBRTE_PDUMP=y
+CONFIG_RTE_LIBRTE_PDUMP=n

Quoted 7 lines

Quoted 4 lines

#
# Compile vhost user library
--
2.1.4

Since, you already mentioned in other mail to Ferruh that config flag disabling patches are only for testers compilation purpose and you have plans to make proper fix by end of June. I will wait on for actual patch.

Quoted 4 lines

I said I planned to do so, but found out that I would not have enough time before the end of June. Sorry about the ambiguous phrasing.

Do you think you will be able to fix this library in time?

KNI uses / depends pci, I am not sure what to fix here.

The problem to enable the KNI is build dependency problem, right?

I guess problem will be fixes if we can build in following order:
- lib/eal
- drivers/bus
- lib
- drivers

This was the case when bus drives compiled within eal. What do you think about this build order?

Quoted 6 lines

Quoted 5 lines

Please see if rte_pci.h can be removed from the includes of rte_pdump.c , might be unnecessary include.

Thanks,
Reshma

Hi Ferruh,

Quoted 43 lines · Ferruh Yigit

Quoted 33 lines · Gaëtan Rivet

Hi Reshma,

Quoted 22 lines · Reshma

Hi,

Quoted 20 lines

-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of Gaetan Rivet
Sent: Thursday, June 8, 2017 12:59 AM
To: [email protected]
Cc: Gaetan Rivet <[email protected]>
Subject: [dpdk-dev] [PATCH v2 07/12] pdump: disabled by default

Signed-off-by Gaetan Rivet <[email protected]>

---
 config/common_base | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

config/common_base index renamed from config/common_base +0 -0

cade611..8ec5e4e 100644

config/common_base +0 -0

@@ -700,7 +700,7 @@ CONFIG_RTE_KNI_PREEMPT_DEFAULT=y  #  # Compile

the pdump library # -CONFIG_RTE_LIBRTE_PDUMP=y
+CONFIG_RTE_LIBRTE_PDUMP=n

Quoted 7 lines

Quoted 4 lines

#
# Compile vhost user library
--
2.1.4

Since, you already mentioned in other mail to Ferruh that config flag disabling patches are only for testers compilation purpose and you have plans to make proper fix by end of June. I will wait on for actual patch.

Quoted 4 lines

I said I planned to do so, but found out that I would not have enough time before the end of June. Sorry about the ambiguous phrasing.

Do you think you will be able to fix this library in time?

KNI uses / depends pci, I am not sure what to fix here.

The problem to enable the KNI is build dependency problem, right?

Quoted 9 lines

I guess problem will be fixes if we can build in following order:
- lib/eal
- drivers/bus
- lib
- drivers

This was the case when bus drives compiled within eal. What do you think about this build order?

Yes, that build order would fix the issue.
However, IMO this is not the proper way to proceed.
It obscures the architecture, the distinction between DPDK abstractions and their implementations.

Looking quickly into this dependency, it seems that the PCI info is only used during allocation, and only to register PCI information within device infos. They do not seem used afterward at the library level, except to print some device description upon device start.

They can be completely removed from KNI (both from the lib and the driver), without breaking the compilation.
This however changes the API of rte_kni_alloc() and the ABI of rte_kni_conf.

But it seems better than changing the build order and opening a can of all kind of worms, allowing a few libraries to skirt around their duty to remain generic and independent from abstraction implementations.

Ideally KNI interfaces should be able to use any rte_device, not only PCI. But if it is forced to use only PCI devices, then pointing to an rte_pci_device seems a better way to proceed, as it has all those infos readily available. It would allow the PCI device to grow and evolve without breaking the KNI lib.

Anyway, I think there are several possible solutions to this, before resorting to modifying the build order.

Quoted 8 lines

Quoted 7 lines

Quoted 6 lines

Please see if rte_pci.h can be removed from the includes of rte_pdump.c , might be unnecessary include.

Thanks,
Reshma

-----Original Message-----
From: Gaëtan Rivet [mailto:[email protected]]
Sent: Sunday, June 11, 2017 8:42 PM
To: Pattan, Reshma <[email protected]>
Cc: [email protected]
Subject: Re: [dpdk-dev] [PATCH v2 07/12] pdump: disabled by default

Quoted 2 lines

Since, you already mentioned in other mail to Ferruh that config flag

disabling patches are only for testers compilation purpose and you have plans to make proper fix by end of June. I will wait on for actual patch.

Quoted 1 line

I said I planned to do so, but found out that I would not have enough time before the end of June. Sorry about the ambiguous phrasing.

Do you think you will be able to fix this library in time?

Hi,

Quoted 13 lines

-----Original Message-----
From: Gaëtan Rivet [mailto:[email protected]]
Sent: Sunday, June 11, 2017 8:42 PM
To: Pattan, Reshma <[email protected]>
Cc: [email protected]
Subject: Re: [dpdk-dev] [PATCH v2 07/12] pdump: disabled by default

Quoted 2 lines

Since, you already mentioned in other mail to Ferruh that config flag

disabling patches are only for testers compilation purpose and you have plans to make proper fix by end of June. I will wait on for actual patch.

Quoted 1 line

Quoted 4 lines

I said I planned to do so, but found out that I would not have enough time before the end of June. Sorry about the ambiguous phrasing.

Do you think you will be able to fix this library in time?

rte_pci.h is unnecessary include in rte_pdump.c, hence I removed it and sent the patch.

Thanks,
Reshma

Signed-off-by Gaetan Rivet <[email protected]>

---
 config/common_linuxapp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

config/common_linuxapp +0 -0

index b3cf41b..cc85cc6 100644

Quoted 11 lines · Gaetan Rivet

Signed-off-by Gaetan Rivet <[email protected]>

---
 config/common_linuxapp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

config/common_linuxapp +0 -0

index b3cf41b..cc85cc6 100644

config/common_linuxapp CONFIG_RTE_EXEC_ENV_LINUXAPP=y · line 44

Quoted 8 lines

config/common_linuxapp +1 -1

@@ -38,7 +38,7 @@ CONFIG_RTE_EXEC_ENV_LINUXAPP=y
 CONFIG_RTE_EAL_IGB_UIO=y
 CONFIG_RTE_EAL_VFIO=y
 CONFIG_RTE_KNI_KMOD=y
-CONFIG_RTE_LIBRTE_KNI=y
+CONFIG_RTE_LIBRTE_KNI=n
 CONFIG_RTE_LIBRTE_PMD_KNI=y
 CONFIG_RTE_LIBRTE_VHOST=y
 CONFIG_RTE_LIBRTE_PMD_VHOST=y

Hi Gaetan,

We shouldn't just disable components that doesn't compile.

And what happens when it is enabled, not compiled at all? So you are literally breaking the existing support with your patch?

Thanks,
ferruh

Hi Ferruh,

Quoted 23 lines · Ferruh Yigit

Quoted 11 lines · Gaetan Rivet

Signed-off-by Gaetan Rivet <[email protected]>

---
 config/common_linuxapp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

config/common_linuxapp +0 -0

index b3cf41b..cc85cc6 100644

config/common_linuxapp CONFIG_RTE_EXEC_ENV_LINUXAPP=y · line 44

Quoted 8 lines

config/common_linuxapp +1 -1

@@ -38,7 +38,7 @@ CONFIG_RTE_EXEC_ENV_LINUXAPP=y
 CONFIG_RTE_EAL_IGB_UIO=y
 CONFIG_RTE_EAL_VFIO=y
 CONFIG_RTE_KNI_KMOD=y
-CONFIG_RTE_LIBRTE_KNI=y
+CONFIG_RTE_LIBRTE_KNI=n
 CONFIG_RTE_LIBRTE_PMD_KNI=y
 CONFIG_RTE_LIBRTE_VHOST=y
 CONFIG_RTE_LIBRTE_PMD_VHOST=y

Hi Gaetan,

Quoted 2 lines

We shouldn't just disable components that doesn't compile.

Ah, sure :) . This patch is not meant to be integrated as is, but only as a convenient way for testers to apply the patchset and verify the compilation, as far as KNI is not concerned.

Eventdev and cryptodev fixed this dependency. I was thinking about looking into it for KNI and PDUMP but I don't have the time right now, and I'm not sure I will have until the end of June.

Quoted 4 lines

KNI uses / depends pci, I am not sure what to fix here.

The problem to enable the KNI is build dependency problem, right?

Quoted 9 lines

I guess problem will be fixes if we can build in following order:
- lib/eal
- drivers/bus
- lib
- drivers

This was the case when bus drives compiled within eal. What do you think about this build order?

Yes, that build order would fix the issue.
However, IMO this is not the proper way to proceed.
It obscures the architecture, the distinction between DPDK abstractions and their implementations.

Looking quickly into this dependency, it seems that the PCI info is only used during allocation, and only to register PCI information within device infos. They do not seem used afterward at the library level, except to print some device description upon device start.

They can be completely removed from KNI (both from the lib and the driver), without breaking the compilation.
This however changes the API of rte_kni_alloc() and the ABI of rte_kni_conf.

But it seems better than changing the build order and opening a can of all kind of worms, allowing a few libraries to skirt around their duty to remain generic and independent from abstraction implementations.

Ideally KNI interfaces should be able to use any rte_device, not only PCI. But if it is forced to use only PCI devices, then pointing to an rte_pci_device seems a better way to proceed, as it has all those infos readily available. It would allow the PCI device to grow and evolve

breaking the KNI lib.

Anyway, I think there are several possible solutions to this, before resorting to modifying the build order.

Quoted 29 lines · Gaëtan Rivet

Hi Ferruh,

Quoted 23 lines · Ferruh Yigit

Quoted 11 lines · Gaetan Rivet

Signed-off-by Gaetan Rivet <[email protected]>

---
 config/common_linuxapp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

config/common_linuxapp +0 -0

index b3cf41b..cc85cc6 100644

config/common_linuxapp CONFIG_RTE_EXEC_ENV_LINUXAPP=y · line 44

Quoted 8 lines

config/common_linuxapp +1 -1

@@ -38,7 +38,7 @@ CONFIG_RTE_EXEC_ENV_LINUXAPP=y
 CONFIG_RTE_EAL_IGB_UIO=y
 CONFIG_RTE_EAL_VFIO=y
 CONFIG_RTE_KNI_KMOD=y
-CONFIG_RTE_LIBRTE_KNI=y
+CONFIG_RTE_LIBRTE_KNI=n
 CONFIG_RTE_LIBRTE_PMD_KNI=y
 CONFIG_RTE_LIBRTE_VHOST=y
 CONFIG_RTE_LIBRTE_PMD_VHOST=y

Hi Gaetan,

Quoted 2 lines

We shouldn't just disable components that doesn't compile.

Quoted 7 lines

Ah, sure :) . This patch is not meant to be integrated as is, but only as a convenient way for testers to apply the patchset and verify the compilation, as far as KNI is not concerned.

Eventdev and cryptodev fixed this dependency. I was thinking about looking into it for KNI and PDUMP but I don't have the time right now, and I'm not sure I will have until the end of June.

Moved from another mail thread
(http://dpdk.org/ml/archives/dev/2017-June/067936.html)

Quoted 24 lines

Quoted 4 lines

KNI uses / depends pci, I am not sure what to fix here.

The problem to enable the KNI is build dependency problem, right?

Quoted 9 lines

I guess problem will be fixes if we can build in following order:
- lib/eal
- drivers/bus
- lib
- drivers

This was the case when bus drives compiled within eal. What do you think about this build order?

Yes, that build order would fix the issue.
However, IMO this is not the proper way to proceed.
It obscures the architecture, the distinction between DPDK abstractions and their implementations.

Looking quickly into this dependency, it seems that the PCI info is only used during allocation, and only to register PCI information within device infos. They do not seem used afterward at the library level, except to print some device description upon device start.

Quoted 4 lines

They can be completely removed from KNI (both from the lib and the driver), without breaking the compilation.
This however changes the API of rte_kni_alloc() and the ABI of rte_kni_conf.

PCI info is not only for printing, it is required for ethtool support.

The pci info sent to KNI kernel module, which uses this information to associate kernel driver to DPDK interface. Basically this is required for control part support of KNI.

So I believe we can't just remove this.

Quoted 5 lines

Ideally KNI interfaces should be able to use any rte_device, not only PCI. But if it is forced to use only PCI devices, then pointing to an rte_pci_device seems a better way to proceed, as it has all those infos readily available. It would allow the PCI device to grow and evolve without breaking the KNI lib.

Ideally this is good idea to make DPDK libraries bus agnostic.

But for KNI, it is not just lib/librte_kni, it has a kernel module counterpart and it needs to know the bus information, in this manner KNI is different.

Even if we assume it is possible to make KNI independent from bus, this effort is not very useful because we don't want to continue KNI ethtool support as it is (by having Linux NIC drivers in kernel module), so there won't be any other NIC that benefits from update.

And option can be replace KNI ethtool support with KCP, but we are struggling to upstream KCP for a while, and this is another story.

For specific to KNI, we can say, it is a library that is dependent to specific bus. I believe build system should be able to support some components depends to specific bus.

This function was previously private to the EAL layer. Other subsystems requires it, such as the PCI bus.

This function is only exposed for linuxapps.

21/06/2017 01:36, Gaetan Rivet:

Quoted 4 lines

This function was previously private to the EAL layer. Other subsystems requires it, such as the PCI bus.

This function is only exposed for linuxapps.

Why exposing it only for Linux?
Every API should be common, even if it is not implemented for FreeBSD.

Signed-off-by Gaetan Rivet <[email protected]>

21/06/2017 01:36, Gaetan Rivet:

Quoted 1 line

Signed-off-by Gaetan Rivet <[email protected]>

Please add a comment to explain why this include is required now.

pmdinfogen has a dependency on the PCI bus. The latter must be built first.

21/06/2017 01:36, Gaetan Rivet:

Quoted 2 lines

pmdinfogen has a dependency on the PCI bus. The latter must be built first.

I think it should not be moved outside of buildtools.

The build order can be fixed by installing headers before any compilation like proposed in this RFC: http://dpdk.org/patch/25463

Another (probably better) solution is to keep basic definitions and helpers in EAL:
- rte_pci.h keeps only some PCI definitions and helpers
like rte_pci_addr and eal_parse_pci_BDF() in EAL
- bus management is done in the PCI driver

For pmdinfogen, we just need struct rte_pci_id.
Other tools or applications will probably need this kind of basic struct and functions available in EAL.

Quoted 9 lines

Another (probably better) solution is to keep basic definitions and helpers in EAL:
- rte_pci.h keeps only some PCI definitions and helpers
like rte_pci_addr and eal_parse_pci_BDF() in EAL
- bus management is done in the PCI driver

For pmdinfogen, we just need struct rte_pci_id.
Other tools or applications will probably need this kind of basic struct and functions available in EAL.

I mostly agree, this proposal should be kept to a minimum at first for this release and carefully expanded afterward.

If that's ok, I will propose a new version of this patchset with a new librte_pci, that might fix both pmdinfogen and librte_kni.

21/06/2017 11:40, Gaëtan Rivet:

Quoted 11 lines · Thomas Monjalon

Quoted 9 lines

Another (probably better) solution is to keep basic definitions and helpers in EAL:
- rte_pci.h keeps only some PCI definitions and helpers
like rte_pci_addr and eal_parse_pci_BDF() in EAL
- bus management is done in the PCI driver

For pmdinfogen, we just need struct rte_pci_id.
Other tools or applications will probably need this kind of basic struct and functions available in EAL.

Quoted 5 lines

I mostly agree, this proposal should be kept to a minimum at first for this release and carefully expanded afterward.

If that's ok, I will propose a new version of this patchset with a new librte_pci, that might fix both pmdinfogen and librte_kni.

Why creating a new librte_pci instead of just keeping it in EAL?

Quoted 12 lines

21/06/2017 11:40, Gaëtan Rivet:

Quoted 11 lines · Thomas Monjalon

Quoted 9 lines

Another (probably better) solution is to keep basic definitions and helpers in EAL:
- rte_pci.h keeps only some PCI definitions and helpers
like rte_pci_addr and eal_parse_pci_BDF() in EAL
- bus management is done in the PCI driver

For pmdinfogen, we just need struct rte_pci_id.
Other tools or applications will probably need this kind of basic struct and functions available in EAL.

Quoted 7 lines

Quoted 5 lines

I mostly agree, this proposal should be kept to a minimum at first for this release and carefully expanded afterward.

If that's ok, I will propose a new version of this patchset with a new librte_pci, that might fix both pmdinfogen and librte_kni.

Why creating a new librte_pci instead of just keeping it in EAL?

While I agree that it makes sense to have PCI helpers shared among several subsystems, I do not see a reason for the EAL to rely on it.

The EAL is the bedrock of the whole system. Having those helpers within would mean that one expects them to be used to build this bedrock. It would be misleading.

In the context of a framework, aimed at being used by others, an okay architecture is one that works. A good architecture is one that intrinsically convey meaning and explains its goal to developers relying on it. I think that having this PCI lib within EAL just because nothing prevents us from doing so is mistaken, in this regard.

Conversely, the argument about being conservative in the changes, especially to an essential part such as the EAL, is obsolete for this release and this subsystem, as deep changes are necessary anyway, and the design should be right from the get go to allow further stability.

Finally, the PCI lib and bus is also an example for other developers. I do not think that all other hardware buses should be allowed in adding their own specific helpers to the EAL. In this regard, there is no reason to have an exception made just for the PCI lib.

This patchset moves the PCI bus out of the EAL to the drivers/bus subdirectory.

Almost all dependencies have been worked out, only remains KNI to be made fully independent from the PCI bus in its lib section.

This patchset includes a patch disabling it, that should be removed before integration, once all dependencies have been fixed.

The pmdinfogen app has been moved to the drivers subdirectory. This allows using the dependency syntax from the build system, as this app also depends on the PCI bus. The dependency graph is as follows:

drivers/bus/pci
|
+ drivers/pmdinfogen
|
+ drivers/net

The compilation has been tested on debian 8, Redhat 7.2 and FreeBSD 10.3

This patchset depends on:

eal: complete attach / detach support
http://dpdk.org/ml/archives/dev/2017-June/067057.html
http://dpdk.org/dev/patchwork/patch/24969/

v1 -> v2:

This patchet now depends also on the eventdev PCI dependency fix:

[PATCH v2 0/4] Remove PCI and VDEV dependency from eventdev library
http://dpdk.org/ml/archives/dev/2017-June/067402.html
http://dpdk.org/dev/patchwork/patch/25092/

* Fixes a few PCI dependency left
* While wholes files are moved, fixed a few checkpatch warnings to start anew.
* Updated eventdev and cryptodev build dependencies

People who want to evaluate / test the whole system can clone:
https://github.com/grivet/dpdk/tree/master-net

v3:

Further checkpatch fixes have been applied upon the new bus.
Both cryptodev and pdump have been fixed. The patches disabling them have been removed.
This patchset now depends on both the cryptodev and pdump dependency fixes:

[dpdk-dev] [PATCH 00/12] Remove cryptodev driver
http://dpdk.org/ml/archives/dev/2017-May/066382.html

[dpdk-dev] [PATCH] pdump: remove unnecessary header file
http://dpdk.org/ml/archives/dev/2017-June/067785.html

My tree has been updated to follow the latest state of the patchsets currently live on the ML:
https://github.com/grivet/dpdk/tree/master-net

Gaetan Rivet (9):
kni: disabled by default
eal: expose rte_eal_using_phys_addrs
ethdev: remove useless PCI dependency
bus: properly include rte_debug
pmdinfogen: move to drivers subdirectory
bus/pci: introduce pci bus
bus/pci: follow checkpatch
drivers: update eventdev dependencies
drivers: update cryptodev dependencies

  GNUmakefile                                     |   2 +-
  MAINTAINERS                                     |   2 +-
  buildtools/Makefile                             |  36 --
  buildtools/pmdinfogen/Makefile                  |  47 --
  buildtools/pmdinfogen/pmdinfogen.c              | 422 --------------
  buildtools/pmdinfogen/pmdinfogen.h              | 125 ----
  config/common_base                              |  10 +
  config/common_linuxapp                          |   2 +-
  drivers/Makefile                                |   7 +-
  drivers/bus/Makefile                            |   2 +
  drivers/bus/pci/Makefile                        |  60 ++
  drivers/bus/pci/bsd/Makefile                    |  32 ++
  drivers/bus/pci/bsd/rte_bus_pci_version.map     |  21 +
  drivers/bus/pci/bsd/rte_pci.c                   | 671 ++++++++++++++++++++++
  drivers/bus/pci/include/rte_pci.h               | 656 +++++++++++++++++++++
  drivers/bus/pci/linux/Makefile                  |  37 ++
  drivers/bus/pci/linux/rte_bus_pci_version.map   |  21 +
  drivers/bus/pci/linux/rte_pci.c                 | 722 +++++++++++++++++++++++
  drivers/bus/pci/linux/rte_pci_init.h            |  97 ++++
  drivers/bus/pci/linux/rte_pci_uio.c             | 571 +++++++++++++++++++
  drivers/bus/pci/linux/rte_pci_vfio.c            | 684 ++++++++++++++++++++++
  drivers/bus/pci/linux/rte_vfio_mp_sync.c        | 424 ++++++++++++++
  drivers/bus/pci/private.h                       | 169 ++++++
  drivers/bus/pci/rte_pci_common.c                | 601 ++++++++++++++++++++
  drivers/bus/pci/rte_pci_common_uio.c            | 234 ++++++++
  drivers/pmdinfogen/Makefile                     |  47 ++
  drivers/pmdinfogen/pmdinfogen.c                 | 422 ++++++++++++++
  drivers/pmdinfogen/pmdinfogen.h                 | 125 ++++
  lib/librte_eal/bsdapp/eal/Makefile              |   3 -
  lib/librte_eal/bsdapp/eal/eal.c                 |   1 -
  lib/librte_eal/bsdapp/eal/eal_pci.c             | 672 ----------------------
  lib/librte_eal/bsdapp/eal/rte_eal_version.map   |  15 -
  lib/librte_eal/common/Makefile                  |   2 +-
  lib/librte_eal/common/eal_common_bus.c          |   1 +
  lib/librte_eal/common/eal_common_pci.c          | 603 --------------------
  lib/librte_eal/common/eal_common_pci_uio.c      | 233 --------
  lib/librte_eal/common/eal_private.h             | 138 -----
  lib/librte_eal/common/include/rte_pci.h         | 601 --------------------
  lib/librte_eal/linuxapp/eal/Makefile            |  12 +-
  lib/librte_eal/linuxapp/eal/eal.c               |   1 -
  lib/librte_eal/linuxapp/eal/eal_interrupts.c    |   1 -
  lib/librte_eal/linuxapp/eal/eal_memory.c        |   3 +-
  lib/librte_eal/linuxapp/eal/eal_pci.c           | 723 ------------------------
  lib/librte_eal/linuxapp/eal/eal_pci_init.h      |  97 ----
  lib/librte_eal/linuxapp/eal/eal_pci_uio.c       | 567 -------------------
  lib/librte_eal/linuxapp/eal/eal_pci_vfio.c      | 674 ----------------------
  lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c  | 424 --------------
  lib/librte_eal/linuxapp/eal/rte_eal_version.map |  16 +-
  lib/librte_eal/linuxapp/eal/rte_memory_linux.h  |  64 +++
  lib/librte_ether/rte_ethdev.c                   |   1 -
  mk/rte.app.mk                                   |   2 +
  51 files changed, 5687 insertions(+), 5416 deletions(-)

delete mode 100644 buildtools/Makefile
delete mode 100644 buildtools/pmdinfogen/Makefile delete mode 100644 buildtools/pmdinfogen/pmdinfogen.c delete mode 100644 buildtools/pmdinfogen/pmdinfogen.h create mode 100644 drivers/bus/pci/Makefile
create mode 100644 drivers/bus/pci/bsd/Makefile
create mode 100644 drivers/bus/pci/bsd/rte_bus_pci_version.map create mode 100644 drivers/bus/pci/bsd/rte_pci.c create mode 100644 drivers/bus/pci/include/rte_pci.h create mode 100644 drivers/bus/pci/linux/Makefile create mode 100644 drivers/bus/pci/linux/rte_bus_pci_version.map create mode 100644 drivers/bus/pci/linux/rte_pci.c create mode 100644 drivers/bus/pci/linux/rte_pci_init.h create mode 100644 drivers/bus/pci/linux/rte_pci_uio.c create mode 100644 drivers/bus/pci/linux/rte_pci_vfio.c create mode 100644 drivers/bus/pci/linux/rte_vfio_mp_sync.c create mode 100644 drivers/bus/pci/private.h
create mode 100644 drivers/bus/pci/rte_pci_common.c create mode 100644 drivers/bus/pci/rte_pci_common_uio.c create mode 100644 drivers/pmdinfogen/Makefile
create mode 100644 drivers/pmdinfogen/pmdinfogen.c create mode 100644 drivers/pmdinfogen/pmdinfogen.h delete mode 100644 lib/librte_eal/bsdapp/eal/eal_pci.c delete mode 100644 lib/librte_eal/common/eal_common_pci.c delete mode 100644 lib/librte_eal/common/eal_common_pci_uio.c delete mode 100644 lib/librte_eal/common/include/rte_pci.h delete mode 100644 lib/librte_eal/linuxapp/eal/eal_pci.c delete mode 100644 lib/librte_eal/linuxapp/eal/eal_pci_init.h delete mode 100644 lib/librte_eal/linuxapp/eal/eal_pci_uio.c delete mode 100644 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c delete mode 100644 lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c create mode 100644 lib/librte_eal/linuxapp/eal/rte_memory_linux.h

Hi Gaetan,

Do you (or anyone else) have plan to move vdev bus into drivers/bus/.

Thanks,
Jianfeng

Quoted 157 lines · Gaetan Rivet

This patchset moves the PCI bus out of the EAL to the drivers/bus subdirectory.

Almost all dependencies have been worked out, only remains KNI to be made fully independent from the PCI bus in its lib section.

This patchset includes a patch disabling it, that should be removed before integration, once all dependencies have been fixed.

The pmdinfogen app has been moved to the drivers subdirectory. This allows using the dependency syntax from the build system, as this app also depends on the PCI bus. The dependency graph is as follows:

drivers/bus/pci
|
+ drivers/pmdinfogen
|
+ drivers/net

The compilation has been tested on debian 8, Redhat 7.2 and FreeBSD 10.3

This patchset depends on:

eal: complete attach / detach support
http://dpdk.org/ml/archives/dev/2017-June/067057.html
http://dpdk.org/dev/patchwork/patch/24969/

v1 -> v2:

This patchet now depends also on the eventdev PCI dependency fix:

[PATCH v2 0/4] Remove PCI and VDEV dependency from eventdev library
http://dpdk.org/ml/archives/dev/2017-June/067402.html
http://dpdk.org/dev/patchwork/patch/25092/

* Fixes a few PCI dependency left
* While wholes files are moved, fixed a few checkpatch warnings to start anew.
* Updated eventdev and cryptodev build dependencies

People who want to evaluate / test the whole system can clone:
https://github.com/grivet/dpdk/tree/master-net

v3:

Further checkpatch fixes have been applied upon the new bus.
Both cryptodev and pdump have been fixed. The patches disabling them have been removed.
This patchset now depends on both the cryptodev and pdump dependency fixes:

[dpdk-dev] [PATCH 00/12] Remove cryptodev driver
http://dpdk.org/ml/archives/dev/2017-May/066382.html

[dpdk-dev] [PATCH] pdump: remove unnecessary header file
http://dpdk.org/ml/archives/dev/2017-June/067785.html

My tree has been updated to follow the latest state of the patchsets currently live on the ML:
https://github.com/grivet/dpdk/tree/master-net

Gaetan Rivet (9):
kni: disabled by default
eal: expose rte_eal_using_phys_addrs
ethdev: remove useless PCI dependency
bus: properly include rte_debug
pmdinfogen: move to drivers subdirectory
bus/pci: introduce pci bus
bus/pci: follow checkpatch
drivers: update eventdev dependencies
drivers: update cryptodev dependencies

 GNUmakefile                                     |   2 +-
 MAINTAINERS                                     |   2 +-
 buildtools/Makefile                             |  36 --
 buildtools/pmdinfogen/Makefile                  |  47 --
 buildtools/pmdinfogen/pmdinfogen.c              | 422 --------------
 buildtools/pmdinfogen/pmdinfogen.h              | 125 ----
 config/common_base                              |  10 +
 config/common_linuxapp                          |   2 +-
 drivers/Makefile                                |   7 +-
 drivers/bus/Makefile                            |   2 +
 drivers/bus/pci/Makefile                        |  60 ++
 drivers/bus/pci/bsd/Makefile                    |  32 ++
 drivers/bus/pci/bsd/rte_bus_pci_version.map     |  21 +
 drivers/bus/pci/bsd/rte_pci.c                   | 671 ++++++++++++++++++++++
 drivers/bus/pci/include/rte_pci.h               | 656 +++++++++++++++++++++
 drivers/bus/pci/linux/Makefile                  |  37 ++
 drivers/bus/pci/linux/rte_bus_pci_version.map   |  21 +
 drivers/bus/pci/linux/rte_pci.c                 | 722 +++++++++++++++++++++++
 drivers/bus/pci/linux/rte_pci_init.h            |  97 ++++
 drivers/bus/pci/linux/rte_pci_uio.c             | 571 +++++++++++++++++++
 drivers/bus/pci/linux/rte_pci_vfio.c            | 684 ++++++++++++++++++++++
 drivers/bus/pci/linux/rte_vfio_mp_sync.c        | 424 ++++++++++++++
 drivers/bus/pci/private.h                       | 169 ++++++
 drivers/bus/pci/rte_pci_common.c                | 601 ++++++++++++++++++++
 drivers/bus/pci/rte_pci_common_uio.c            | 234 ++++++++
 drivers/pmdinfogen/Makefile                     |  47 ++
 drivers/pmdinfogen/pmdinfogen.c                 | 422 ++++++++++++++
 drivers/pmdinfogen/pmdinfogen.h                 | 125 ++++
 lib/librte_eal/bsdapp/eal/Makefile              |   3 -
 lib/librte_eal/bsdapp/eal/eal.c                 |   1 -
 lib/librte_eal/bsdapp/eal/eal_pci.c             | 672 ----------------------
 lib/librte_eal/bsdapp/eal/rte_eal_version.map   |  15 -
 lib/librte_eal/common/Makefile                  |   2 +-
 lib/librte_eal/common/eal_common_bus.c          |   1 +
 lib/librte_eal/common/eal_common_pci.c          | 603 --------------------
 lib/librte_eal/common/eal_common_pci_uio.c      | 233 --------
 lib/librte_eal/common/eal_private.h             | 138 -----
 lib/librte_eal/common/include/rte_pci.h         | 601 --------------------
 lib/librte_eal/linuxapp/eal/Makefile            |  12 +-
 lib/librte_eal/linuxapp/eal/eal.c               |   1 -
 lib/librte_eal/linuxapp/eal/eal_interrupts.c    |   1 -
 lib/librte_eal/linuxapp/eal/eal_memory.c        |   3 +-
 lib/librte_eal/linuxapp/eal/eal_pci.c           | 723 ------------------------
 lib/librte_eal/linuxapp/eal/eal_pci_init.h      |  97 ----
 lib/librte_eal/linuxapp/eal/eal_pci_uio.c       | 567 -------------------
 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c      | 674 ----------------------
 lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c  | 424 --------------
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |  16 +-
 lib/librte_eal/linuxapp/eal/rte_memory_linux.h  |  64 +++
 lib/librte_ether/rte_ethdev.c                   |   1 -
 mk/rte.app.mk                                   |   2 +
 51 files changed, 5687 insertions(+), 5416 deletions(-)
 delete mode 100644 buildtools/Makefile
 delete mode 100644 buildtools/pmdinfogen/Makefile
 delete mode 100644 buildtools/pmdinfogen/pmdinfogen.c
 delete mode 100644 buildtools/pmdinfogen/pmdinfogen.h
 create mode 100644 drivers/bus/pci/Makefile
 create mode 100644 drivers/bus/pci/bsd/Makefile
 create mode 100644 drivers/bus/pci/bsd/rte_bus_pci_version.map
 create mode 100644 drivers/bus/pci/bsd/rte_pci.c
 create mode 100644 drivers/bus/pci/include/rte_pci.h
 create mode 100644 drivers/bus/pci/linux/Makefile
 create mode 100644 drivers/bus/pci/linux/rte_bus_pci_version.map
 create mode 100644 drivers/bus/pci/linux/rte_pci.c
 create mode 100644 drivers/bus/pci/linux/rte_pci_init.h
 create mode 100644 drivers/bus/pci/linux/rte_pci_uio.c
 create mode 100644 drivers/bus/pci/linux/rte_pci_vfio.c
 create mode 100644 drivers/bus/pci/linux/rte_vfio_mp_sync.c
 create mode 100644 drivers/bus/pci/private.h
 create mode 100644 drivers/bus/pci/rte_pci_common.c
 create mode 100644 drivers/bus/pci/rte_pci_common_uio.c
 create mode 100644 drivers/pmdinfogen/Makefile
 create mode 100644 drivers/pmdinfogen/pmdinfogen.c
 create mode 100644 drivers/pmdinfogen/pmdinfogen.h
 delete mode 100644 lib/librte_eal/bsdapp/eal/eal_pci.c
 delete mode 100644 lib/librte_eal/common/eal_common_pci.c
 delete mode 100644 lib/librte_eal/common/eal_common_pci_uio.c
 delete mode 100644 lib/librte_eal/common/include/rte_pci.h
 delete mode 100644 lib/librte_eal/linuxapp/eal/eal_pci.c
 delete mode 100644 lib/librte_eal/linuxapp/eal/eal_pci_init.h
 delete mode 100644 lib/librte_eal/linuxapp/eal/eal_pci_uio.c
 delete mode 100644 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
 delete mode 100644 lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c
 create mode 100644 lib/librte_eal/linuxapp/eal/rte_memory_linux.h

Hi Jianfeng,

Quoted 3 lines · Jianfeng

Hi Gaetan,

Do you (or anyone else) have plan to move vdev bus into drivers/bus/.

It is in the roadmap for the DPDK, but I haven't planned to do it.

23/06/2017 10:19, Gaëtan Rivet:

Quoted 7 lines

Hi Jianfeng,

Quoted 3 lines · Jianfeng

Hi Gaetan,

Do you (or anyone else) have plan to move vdev bus into drivers/bus/.

It is in the roadmap for the DPDK, but I haven't planned to do it.

We need to move vdev in drivers/bus/ to complete the bus rework.

Any volunteer?

Hi Thomas & Gaetan,

Quoted 7 lines · Thomas Monjalon

23/06/2017 10:19, Gaëtan Rivet:

Quoted 6 lines

Hi Jianfeng,

Quoted 3 lines · Jianfeng

Hi Gaetan,

Do you (or anyone else) have plan to move vdev bus into drivers/bus/.

Quoted 5 lines

Quoted 1 line

It is in the roadmap for the DPDK, but I haven't planned to do it.

We need to move vdev in drivers/bus/ to complete the bus rework.

Any volunteer?

Actually I have a version when I'm trying to support vdev in primary/secondary mode. I would love to send it out for review.