[dpdk-dev] [PATCH 0/2] add MRVL MVPP2 PMD to meson

[dpdk-dev] [PATCH 0/2] add MRVL MVPP2 PMD to meson

[Tomasz Duszynski]

This patchseries adds MRVL MVPP2 PMD to meson build system.

Tomasz Duszynski (2):
  net/mvpp2: rename the version file to standard
  net/mvpp2: add meson build file

 drivers/net/meson.build                            |  2 +-
 drivers/net/mvpp2/Makefile                         |  2 +-
 drivers/net/mvpp2/meson.build                      | 25 ++++++++++++++++++++++
 ..._mrvl_version.map => rte_pmd_mvpp2_version.map} |  0
 4 files changed, 27 insertions(+), 2 deletions(-)
 create mode 100644 drivers/net/mvpp2/meson.build
 rename drivers/net/mvpp2/{rte_pmd_mrvl_version.map => rte_pmd_mvpp2_version.map} (100%)

--
2.7.4

[dpdk-dev] [PATCH 1/2] net/mvpp2: rename the version file to standard

[Tomasz Duszynski]

Rename the version file to follow standard naming convention.

Signed-off-by: Tomasz Duszynski <tdu@semihalf.com>
---
 drivers/net/mvpp2/Makefile                                              | 2 +-
 .../net/mvpp2/{rte_pmd_mrvl_version.map => rte_pmd_mvpp2_version.map}   | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename drivers/net/mvpp2/{rte_pmd_mrvl_version.map => rte_pmd_mvpp2_version.map} (100%)

diff --git a/drivers/net/mvpp2/Makefile b/drivers/net/mvpp2/Makefile
index 2383ec1..492aef9 100644
--- a/drivers/net/mvpp2/Makefile
+++ b/drivers/net/mvpp2/Makefile
@@ -20,7 +20,7 @@ LIB = librte_pmd_mvpp2.a
 LIBABIVER := 1
 
 # versioning export map
-EXPORT_MAP := rte_pmd_mrvl_version.map
+EXPORT_MAP := rte_pmd_mvpp2_version.map
 
 # external library dependencies
 CFLAGS += -I$(LIBMUSDK_PATH)/include
diff --git a/drivers/net/mvpp2/rte_pmd_mrvl_version.map b/drivers/net/mvpp2/rte_pmd_mvpp2_version.map
similarity index 100%
rename from drivers/net/mvpp2/rte_pmd_mrvl_version.map
rename to drivers/net/mvpp2/rte_pmd_mvpp2_version.map
-- 
2.7.4

[dpdk-dev] [PATCH 2/2] net/mvpp2: add meson build file

[Tomasz Duszynski]

Add support for building MRVL MVPP2 PMD with meson.

Signed-off-by: Tomasz Duszynski <tdu@semihalf.com>
---
 drivers/net/meson.build       |  2 +-
 drivers/net/mvpp2/meson.build | 25 +++++++++++++++++++++++++
 2 files changed, 26 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/mvpp2/meson.build

diff --git a/drivers/net/meson.build b/drivers/net/meson.build
index b7cac4a..b7d00a0 100644
--- a/drivers/net/meson.build
+++ b/drivers/net/meson.build
@@ -3,7 +3,7 @@
 
 drivers = ['af_packet', 'axgbe', 'bonding', 'dpaa', 'dpaa2',
 	'e1000', 'enic', 'fm10k', 'i40e', 'ixgbe',
-	'null', 'octeontx', 'pcap', 'ring',
+	'mvpp2', 'null', 'octeontx', 'pcap', 'ring',
 	'sfc', 'thunderx', 'virtio']
 std_deps = ['ethdev', 'kvargs'] # 'ethdev' also pulls in mbuf, net, eal etc
 std_deps += ['bus_pci']         # very many PMDs depend on PCI, so make std
diff --git a/drivers/net/mvpp2/meson.build b/drivers/net/mvpp2/meson.build
new file mode 100644
index 0000000..6ea13ee
--- /dev/null
+++ b/drivers/net/mvpp2/meson.build
@@ -0,0 +1,25 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2018 Marvell International Ltd.
+# Copyright(c) 2018 Semihalf.
+# All rights reserved.
+
+path = run_command('printenv', 'LIBMUSDK_PATH').stdout().strip()
+lib_dir = path + '/lib'
+inc_dir = path + '/include'
+
+lib = cc.find_library('libmusdk', dirs : [lib_dir], required: false)
+if not lib.found()
+	build = false
+else
+	ext_deps += lib
+	includes += include_directories(inc_dir)
+	cflags += ['-DMVCONF_TYPES_PUBLIC', '-DMVCONF_DMA_PHYS_ADDR_T_PUBLIC']
+endif
+
+sources = files(
+	'mrvl_ethdev.c',
+	'mrvl_flow.c',
+	'mrvl_qos.c'
+)
+
+deps += ['cfgfile']
-- 
2.7.4

Re: [dpdk-dev] [PATCH 0/2] add MRVL MVPP2 PMD to meson

[Bruce Richardson]

On Wed, Apr 11, 2018 at 01:45:05PM +0200, Tomasz Duszynski wrote:
> This patchseries adds MRVL MVPP2 PMD to meson build system.
> 
> Tomasz Duszynski (2):
>   net/mvpp2: rename the version file to standard
>   net/mvpp2: add meson build file
>

The patches look ok to me as far as the meson code is concerned, but I have
no way to test compilation etc. It doesn't cause issues with other x86 or
arm builds though, so:

Series Acked-by: Bruce Richardson <bruce.richardson@intel.com>

Re: [dpdk-dev] [PATCH 0/2] add MRVL MVPP2 PMD to meson

[Bruce Richardson]

On Fri, Apr 13, 2018 at 05:12:19PM +0100, Bruce Richardson wrote:
> On Wed, Apr 11, 2018 at 01:45:05PM +0200, Tomasz Duszynski wrote:
> > This patchseries adds MRVL MVPP2 PMD to meson build system.
> > 
> > Tomasz Duszynski (2):
> >   net/mvpp2: rename the version file to standard
> >   net/mvpp2: add meson build file
> >
> 
> The patches look ok to me as far as the meson code is concerned, but I have
> no way to test compilation etc. It doesn't cause issues with other x86 or
> arm builds though, so:
> 
> Series Acked-by: Bruce Richardson <bruce.richardson@intel.com>

Applied to dpdk-next-build

/Bruce

Re: [dpdk-dev] [PATCH 0/2] add MRVL MVPP2 PMD to meson

[Bruce Richardson]

On Fri, Apr 13, 2018 at 05:12:19PM +0100, Bruce Richardson wrote:
> On Wed, Apr 11, 2018 at 01:45:05PM +0200, Tomasz Duszynski wrote:
> > This patchseries adds MRVL MVPP2 PMD to meson build system.
> > 
> > Tomasz Duszynski (2):
> >   net/mvpp2: rename the version file to standard
> >   net/mvpp2: add meson build file
> >
> 
> The patches look ok to me as far as the meson code is concerned, but I have
> no way to test compilation etc. It doesn't cause issues with other x86 or
> arm builds though, so:
> 
> Series Acked-by: Bruce Richardson <bruce.richardson@intel.com>

+Pablo, who is looking at the crypto driver which is similar.

I've just realised at this stage - while looking at something similar with
the turbo_sw baseband driver - that the use of environmental variables is
probably going to cause us problems down the line here. In the case of
cross-compilation, the meson build is going to pull the environment
variable of the host, and use that, even in cases where there is no
cross-compile library available.

I think that for cases like this, using a build option is a better
solution. It explicitly can be set for each independent build, avoiding the
cross-build issues I refer to, and also prevents us having issues with
changing the path in the environment and meson not recognising the change
(environment variables are not tracked for reconfigure, unlike options).

So, would you be ok with changing this to take the MUSDK path from a meson
option rather than the environment?

/Bruce

Re: [dpdk-dev] [PATCH 0/2] add MRVL MVPP2 PMD to meson

[Tomasz Duszynski]

On Wed, Apr 18, 2018 at 04:02:30PM +0100, Bruce Richardson wrote:
> On Fri, Apr 13, 2018 at 05:12:19PM +0100, Bruce Richardson wrote:
> > On Wed, Apr 11, 2018 at 01:45:05PM +0200, Tomasz Duszynski wrote:
> > > This patchseries adds MRVL MVPP2 PMD to meson build system.
> > >
> > > Tomasz Duszynski (2):
> > >   net/mvpp2: rename the version file to standard
> > >   net/mvpp2: add meson build file
> > >
> >
> > The patches look ok to me as far as the meson code is concerned, but I have
> > no way to test compilation etc. It doesn't cause issues with other x86 or
> > arm builds though, so:
> >
> > Series Acked-by: Bruce Richardson <bruce.richardson@intel.com>
>
> +Pablo, who is looking at the crypto driver which is similar.
>
> I've just realised at this stage - while looking at something similar with
> the turbo_sw baseband driver - that the use of environmental variables is
> probably going to cause us problems down the line here. In the case of
> cross-compilation, the meson build is going to pull the environment
> variable of the host, and use that, even in cases where there is no
> cross-compile library available.
>
> I think that for cases like this, using a build option is a better
> solution. It explicitly can be set for each independent build, avoiding the
> cross-build issues I refer to, and also prevents us having issues with
> changing the path in the environment and meson not recognising the change
> (environment variables are not tracked for reconfigure, unlike options).
>
> So, would you be ok with changing this to take the MUSDK path from a meson
> option rather than the environment?
>
> /Bruce

I am okay with the proposed change. As for crypto patch I'll prepare v2.

--
- Tomasz Duszyński

Re: [dpdk-dev] [PATCH 0/2] add MRVL MVPP2 PMD to meson

[Bruce Richardson]

On Thu, Apr 19, 2018 at 10:55:33AM +0200, Tomasz Duszynski wrote:
> On Wed, Apr 18, 2018 at 04:02:30PM +0100, Bruce Richardson wrote:
> > On Fri, Apr 13, 2018 at 05:12:19PM +0100, Bruce Richardson wrote:
> > > On Wed, Apr 11, 2018 at 01:45:05PM +0200, Tomasz Duszynski wrote:
> > > > This patchseries adds MRVL MVPP2 PMD to meson build system.
> > > >
> > > > Tomasz Duszynski (2):
> > > >   net/mvpp2: rename the version file to standard
> > > >   net/mvpp2: add meson build file
> > > >
> > >
> > > The patches look ok to me as far as the meson code is concerned, but I have
> > > no way to test compilation etc. It doesn't cause issues with other x86 or
> > > arm builds though, so:
> > >
> > > Series Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> >
> > +Pablo, who is looking at the crypto driver which is similar.
> >
> > I've just realised at this stage - while looking at something similar with
> > the turbo_sw baseband driver - that the use of environmental variables is
> > probably going to cause us problems down the line here. In the case of
> > cross-compilation, the meson build is going to pull the environment
> > variable of the host, and use that, even in cases where there is no
> > cross-compile library available.
> >
> > I think that for cases like this, using a build option is a better
> > solution. It explicitly can be set for each independent build, avoiding the
> > cross-build issues I refer to, and also prevents us having issues with
> > changing the path in the environment and meson not recognising the change
> > (environment variables are not tracked for reconfigure, unlike options).
> >
> > So, would you be ok with changing this to take the MUSDK path from a meson
> > option rather than the environment?
> >
> > /Bruce
> 
> I am okay with the proposed change. As for crypto patch I'll prepare v2.
> 
> --
> - Tomasz Duszyński

Thanks.