[PATCH 0/4] catch up TILE-Gx support in DPDK

[PATCH 0/4] catch up TILE-Gx support in DPDK

[Chris Metcalf]

This patch series allows DPDK to build for TILE-Gx as of version 17.02.

A required library (libgxio) had not been made publicly available.
It is now available as source here:

  http://www.mellanox.com/repository/solutions/tile-scm/libgxio-1.0.tar.xz

it has also been folded into the binary release of the generic
toolchain that we periodically update on that website; for more
information about the toolchain tarballs, see here:

  http://www.mellanox.com/repository/solutions/tile-scm/

Note that the toolchain components were updated slightly in this release
of the tarballs relative to what was there before.

Hopefully, with DPDK now working on TILE-Gx again, there may be interest
from someone in the community in taking on a maintenance role.  At this
point, the Mellanox engineering team responsible for TILE-Gx is largely
focused on working on future chips based on ARMv8, so unfortunately we
won't have much bandwidth for TILE-Gx support going forward.

If it still seems like removal makes sense now or at some point in the
future, it would probably at least be good to apply these patches so
there is a baseline to pick it up from later.

Liming Sun, the tile dpdk maintainer, has reviewed these changes (he
sits next to me); if it's more appropriate, he can resend these changes
with his Signed-off-by as well.  I took on this work since I was more
familiar with libgxio and the details of our toolchain (I am the
maintainer for the tile architecture for Linux and glibc).

Chris Metcalf (4):
  tile: avoid use of non-upstreamed <arch/cycle.h>
  tile: remove requirement for <arch/mpipe_{xaui,gbe}_def.h headers
  strict alignment: generalize warning handling
  tile: fix remaining build issues

 config/defconfig_tile-tilegx-linuxapp-gcc          |  1 -
 drivers/net/mpipe/mpipe_tilegx.c                   | 36 ++++++++++++++--------
 lib/librte_eal/common/arch/tile/rte_cpuflags.c     |  3 --
 .../common/include/arch/tile/rte_cycles.h          |  4 +--
 mk/arch/tile/rte.vars.mk                           |  5 +++
 mk/toolchain/gcc/rte.vars.mk                       |  4 +--
 6 files changed, 33 insertions(+), 20 deletions(-)

-- 
2.7.2

[PATCH 1/4] tile: avoid use of non-upstreamed <arch/cycle.h>

[Chris Metcalf]

It's trivial to directly invoke a read of the special-purpose
register that holds the clock cycle counter, so just do that.

Signed-off-by: Chris Metcalf <cmetcalf@mellanox.com>
---
 lib/librte_eal/common/include/arch/tile/rte_cycles.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/common/include/arch/tile/rte_cycles.h b/lib/librte_eal/common/include/arch/tile/rte_cycles.h
index 0b2200a3ea75..a87b2f84a21e 100644
--- a/lib/librte_eal/common/include/arch/tile/rte_cycles.h
+++ b/lib/librte_eal/common/include/arch/tile/rte_cycles.h
@@ -37,7 +37,7 @@
 extern "C" {
 #endif
 
-#include <arch/cycle.h>
+#include <arch/spr_def.h>
 
 #include "generic/rte_cycles.h"
 
@@ -50,7 +50,7 @@ extern "C" {
 static inline uint64_t
 rte_rdtsc(void)
 {
-	return get_cycle_count();
+	return __insn_mfspr(SPR_CYCLE);
 }
 
 static inline uint64_t
-- 
2.7.2

[PATCH 2/4] tile: remove requirement for <arch/mpipe_{xaui, gbe}_def.h headers

[Chris Metcalf]

These headers are not part of the set that are upstreamed as part
of glibc or the kernel, and we only need a few defines from each.
The hardware is frozen so these values are not going to change
in any case.

Signed-off-by: Chris Metcalf <cmetcalf@mellanox.com>
---
 drivers/net/mpipe/mpipe_tilegx.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/net/mpipe/mpipe_tilegx.c b/drivers/net/mpipe/mpipe_tilegx.c
index 7bbd168bcb41..adba3306adbc 100644
--- a/drivers/net/mpipe/mpipe_tilegx.c
+++ b/drivers/net/mpipe/mpipe_tilegx.c
@@ -39,11 +39,20 @@
 #include <rte_malloc.h>
 #include <rte_cycles.h>
 
-#include <arch/mpipe_xaui_def.h>
-#include <arch/mpipe_gbe_def.h>
-
 #include <gxio/mpipe.h>
 
+/* mPIPE GBE hardware register definitions. */
+#define MPIPE_GBE_NETWORK_CONFIGURATION 0x8008
+#define MPIPE_GBE_NETWORK_CONFIGURATION__COPY_ALL_SHIFT 4
+#define MPIPE_GBE_NETWORK_CONFIGURATION__MULTI_HASH_ENA_SHIFT 6
+#define MPIPE_GBE_NETWORK_CONFIGURATION__UNI_HASH_ENA_SHIFT 7
+
+/* mPIPE XAUI hardware register definitions. */
+#define MPIPE_XAUI_RECEIVE_CONFIGURATION 0x8020
+#define MPIPE_XAUI_RECEIVE_CONFIGURATION__COPY_ALL_SHIFT 0
+#define MPIPE_XAUI_RECEIVE_CONFIGURATION__ENA_HASH_MULTI_SHIFT 2
+#define MPIPE_XAUI_RECEIVE_CONFIGURATION__ENA_HASH_UNI_SHIFT 3
+
 #ifdef RTE_LIBRTE_MPIPE_PMD_DEBUG
 #define PMD_DEBUG_RX(...)	RTE_LOG(DEBUG, PMD, __VA_ARGS__)
 #define PMD_DEBUG_TX(...)	RTE_LOG(DEBUG, PMD, __VA_ARGS__)
-- 
2.7.2

[PATCH 3/4] strict alignment: generalize warning handling

[Chris Metcalf]

Rather than allowing just armv7 to have non-fatal strict alignment
cast warnings, generalize it to both strict alignment architectures,
armv7 and tile.

Signed-off-by: Chris Metcalf <cmetcalf@mellanox.com>
---
 mk/toolchain/gcc/rte.vars.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mk/toolchain/gcc/rte.vars.mk b/mk/toolchain/gcc/rte.vars.mk
index ff70f3d9f6ad..5caa60004c4e 100644
--- a/mk/toolchain/gcc/rte.vars.mk
+++ b/mk/toolchain/gcc/rte.vars.mk
@@ -81,9 +81,9 @@ ifeq ($(RTE_DEVEL_BUILD),y)
 WERROR_FLAGS += -Werror
 endif
 
-# There are many issues reported for ARMv7 architecture
+# There are many issues reported for strict alignment architectures
 # which are not necessarily fatal. Report as warnings.
-ifeq ($(CONFIG_RTE_ARCH_ARMv7),y)
+ifeq ($(CONFIG_RTE_ARCH_STRICT_ALIGN),y)
 WERROR_FLAGS += -Wno-error=cast-align
 endif
 
-- 
2.7.2

[PATCH 4/4] tile: fix remaining build issues

[Chris Metcalf]

Re-enable CONFIG_RTE_LIBRTE_SCHED, since it is needed to build
correctly.

Fix a few warnings when compiling mpipe_tilegx.c.

Remove an empty rte_cpu_feature_table[] array using a bogus type.

Properly set RTE_OBJCOPY_{TARGET,ARCH} in mk/arch/tile/rte.vars.mk.

Signed-off-by: Chris Metcalf <cmetcalf@mellanox.com>
---
 config/defconfig_tile-tilegx-linuxapp-gcc      |  1 -
 drivers/net/mpipe/mpipe_tilegx.c               | 21 ++++++++++++---------
 lib/librte_eal/common/arch/tile/rte_cpuflags.c |  3 ---
 mk/arch/tile/rte.vars.mk                       |  5 +++++
 4 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/config/defconfig_tile-tilegx-linuxapp-gcc b/config/defconfig_tile-tilegx-linuxapp-gcc
index 44add62567d7..310e876bb4f5 100644
--- a/config/defconfig_tile-tilegx-linuxapp-gcc
+++ b/config/defconfig_tile-tilegx-linuxapp-gcc
@@ -66,7 +66,6 @@ CONFIG_RTE_LIBRTE_ENIC_PMD=n
 # So they're turned off.
 CONFIG_RTE_LIBRTE_LPM=n
 CONFIG_RTE_LIBRTE_ACL=n
-CONFIG_RTE_LIBRTE_SCHED=n
 CONFIG_RTE_LIBRTE_PORT=n
 CONFIG_RTE_LIBRTE_TABLE=n
 CONFIG_RTE_LIBRTE_PIPELINE=n
diff --git a/drivers/net/mpipe/mpipe_tilegx.c b/drivers/net/mpipe/mpipe_tilegx.c
index adba3306adbc..60d5f815f273 100644
--- a/drivers/net/mpipe/mpipe_tilegx.c
+++ b/drivers/net/mpipe/mpipe_tilegx.c
@@ -567,7 +567,7 @@ mpipe_register_segment(struct mpipe_dev_priv *priv, const struct rte_memseg *ms)
 {
 	size_t size = ms->hugepage_sz;
 	uint8_t *addr, *end;
-	int rc;
+	int rc = -EINVAL;
 
 	for (addr = ms->addr, end = addr + ms->len; addr < end; addr += size) {
 		rc = gxio_mpipe_register_page(priv->context, priv->stack, addr,
@@ -1630,6 +1630,17 @@ rte_pmd_mpipe_probe_common(struct rte_vdev_driver *drv, const char *ifname,
 	return 0;
 }
 
+static int rte_pmd_mpipe_xgbe_probe(const char *ifname, const char *params);
+static int rte_pmd_mpipe_gbe_probe(const char *ifname, const char *params);
+
+static struct rte_vdev_driver pmd_mpipe_xgbe_drv = {
+	.probe = rte_pmd_mpipe_xgbe_probe,
+};
+
+static struct rte_vdev_driver pmd_mpipe_gbe_drv = {
+	.probe = rte_pmd_mpipe_gbe_probe,
+};
+
 static int
 rte_pmd_mpipe_xgbe_probe(const char *ifname, const char *params __rte_unused)
 {
@@ -1642,14 +1653,6 @@ rte_pmd_mpipe_gbe_probe(const char *ifname, const char *params __rte_unused)
 	return rte_pmd_mpipe_probe_common(&pmd_mpipe_gbe_drv, ifname, params);
 }
 
-static struct rte_vdev_driver pmd_mpipe_xgbe_drv = {
-	.probe = rte_pmd_mpipe_xgbe_probe,
-};
-
-static struct rte_vdev_driver pmd_mpipe_gbe_drv = {
-	.probe = rte_pmd_mpipe_gbe_probe,
-};
-
 RTE_PMD_REGISTER_VDEV(net_mpipe_xgbe, pmd_mpipe_xgbe_drv);
 RTE_PMD_REGISTER_ALIAS(net_mpipe_xgbe, xgbe);
 RTE_PMD_REGISTER_VDEV(net_mpipe_gbe, pmd_mpipe_gbe_drv);
diff --git a/lib/librte_eal/common/arch/tile/rte_cpuflags.c b/lib/librte_eal/common/arch/tile/rte_cpuflags.c
index a2b6c51a2bc5..0872891352ec 100644
--- a/lib/librte_eal/common/arch/tile/rte_cpuflags.c
+++ b/lib/librte_eal/common/arch/tile/rte_cpuflags.c
@@ -34,9 +34,6 @@
 
 #include <errno.h>
 
-const struct feature_entry rte_cpu_feature_table[] = {
-};
-
 /*
  * Checks if a particular flag is available on current machine.
  */
diff --git a/mk/arch/tile/rte.vars.mk b/mk/arch/tile/rte.vars.mk
index 5ad37389c9a8..2c612c48f6d7 100644
--- a/mk/arch/tile/rte.vars.mk
+++ b/mk/arch/tile/rte.vars.mk
@@ -37,3 +37,8 @@ CPU_LDFLAGS ?=
 CPU_ASFLAGS ?=
 
 export ARCH CROSS CPU_CFLAGS CPU_LDFLAGS CPU_ASFLAGS
+
+RTE_OBJCOPY_TARGET = elf64-tilegx-le
+RTE_OBJCOPY_ARCH = tilegx
+
+export RTE_OBJCOPY_TARGET RTE_OBJCOPY_ARCH
-- 
2.7.2

Re: [PATCH 0/4] catch up TILE-Gx support in DPDK

[Thomas Monjalon]

2017-02-17 20:52, Chris Metcalf:
> This patch series allows DPDK to build for TILE-Gx as of version 17.02.
> 
> A required library (libgxio) had not been made publicly available.
> It is now available as source here:
> 
>   http://www.mellanox.com/repository/solutions/tile-scm/libgxio-1.0.tar.xz
> 
> it has also been folded into the binary release of the generic
> toolchain that we periodically update on that website; for more
> information about the toolchain tarballs, see here:
> 
>   http://www.mellanox.com/repository/solutions/tile-scm/
> 
> Note that the toolchain components were updated slightly in this release
> of the tarballs relative to what was there before.

Thank you.
Some of these changes (being able to compile on a free toolchain) should
have been done since the beginning. Better later than never :)
I think we won't allow any new component in DPDK which cannot be built
freely, in the future (lessons learned).

> Hopefully, with DPDK now working on TILE-Gx again, there may be interest
> from someone in the community in taking on a maintenance role.  At this
> point, the Mellanox engineering team responsible for TILE-Gx is largely
> focused on working on future chips based on ARMv8, so unfortunately we
> won't have much bandwidth for TILE-Gx support going forward.

So do you mean that the TILE-Gx maintainers officially give up on their role?
Then please update the MAINTAINERS file.

> If it still seems like removal makes sense now or at some point in the
> future, it would probably at least be good to apply these patches so
> there is a baseline to pick it up from later.

I agree. We can apply these patches before removing the whole architecture.

> Liming Sun, the tile dpdk maintainer, has reviewed these changes (he
> sits next to me); if it's more appropriate, he can resend these changes
> with his Signed-off-by as well.  I took on this work since I was more
> familiar with libgxio and the details of our toolchain (I am the
> maintainer for the tile architecture for Linux and glibc).

I think it is OK as is.

Re: [PATCH 0/4] catch up TILE-Gx support in DPDK

[Olga Shern]

Hi Thomas,  All

Mellanox agrees to remove TILE-Gx support from DPDK.org, but will continue to support customers using DPDK. 
Customer that needs support should contact Mellanox directly.

Best Regards,
Olga


> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Saturday, February 18, 2017 11:30 AM
> To: Chris Metcalf <cmetcalf@mellanox.com>
> Cc: Vincent JARDIN <vincent.jardin@6wind.com>; Bruce Richardson
> <bruce.richardson@intel.com>; Jerin Jacob
> <jerin.jacob@caviumnetworks.com>; Olivier Matz
> <olivier.matz@6wind.com>; Liming Sun <lsun@mellanox.com>; Olga Shern
> <olgas@mellanox.com>; Yael Shenhav <yaeli@mellanox.com>;
> dev@dpdk.org
> Subject: Re: [PATCH 0/4] catch up TILE-Gx support in DPDK
> 
> 2017-02-17 20:52, Chris Metcalf:
> > This patch series allows DPDK to build for TILE-Gx as of version 17.02.
> >
> > A required library (libgxio) had not been made publicly available.
> > It is now available as source here:
> >
> >
> > http://www.mellanox.com/repository/solutions/tile-scm/libgxio-1.0.tar.
> > xz
> >
> > it has also been folded into the binary release of the generic
> > toolchain that we periodically update on that website; for more
> > information about the toolchain tarballs, see here:
> >
> >   http://www.mellanox.com/repository/solutions/tile-scm/
> >
> > Note that the toolchain components were updated slightly in this
> > release of the tarballs relative to what was there before.
> 
> Thank you.
> Some of these changes (being able to compile on a free toolchain) should
> have been done since the beginning. Better later than never :) I think we
> won't allow any new component in DPDK which cannot be built freely, in the
> future (lessons learned).
> 
> > Hopefully, with DPDK now working on TILE-Gx again, there may be
> > interest from someone in the community in taking on a maintenance
> > role.  At this point, the Mellanox engineering team responsible for
> > TILE-Gx is largely focused on working on future chips based on ARMv8,
> > so unfortunately we won't have much bandwidth for TILE-Gx support going
> forward.
> 
> So do you mean that the TILE-Gx maintainers officially give up on their role?
> Then please update the MAINTAINERS file.
> 
> > If it still seems like removal makes sense now or at some point in the
> > future, it would probably at least be good to apply these patches so
> > there is a baseline to pick it up from later.
> 
> I agree. We can apply these patches before removing the whole
> architecture.
> 
> > Liming Sun, the tile dpdk maintainer, has reviewed these changes (he
> > sits next to me); if it's more appropriate, he can resend these
> > changes with his Signed-off-by as well.  I took on this work since I
> > was more familiar with libgxio and the details of our toolchain (I am
> > the maintainer for the tile architecture for Linux and glibc).
> 
> I think it is OK as is.

Re: [PATCH 0/4] catch up TILE-Gx support in DPDK

[Bruce Richardson]

On Mon, Feb 20, 2017 at 08:24:43PM +0000, Olga Shern wrote:
> Hi Thomas,  All
> 
> Mellanox agrees to remove TILE-Gx support from DPDK.org, but will continue to support customers using DPDK. 
> Customer that needs support should contact Mellanox directly.
> 
> Best Regards,
> Olga
>
Thank you for the clear response. It's a big help to the project for
moving forward, rather than just waiting for an answer that may never
come.

Regards,
/Bruce

Re: [PATCH 0/4] catch up TILE-Gx support in DPDK

[Liming Sun]

>> So do you mean that the TILE-Gx maintainers officially give up on their role?
>> Then please update the MAINTAINERS file.

Yes. Please update the MAINTAINERS file as needed.
Chris Metcalf is out this week. I could submit a separate patch for the MAINTAINERS file if it's required. Or we could wait a little bit until Chris comes back.

Thanks,
Liming

-----Original Message-----
From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] 
Sent: Saturday, February 18, 2017 4:30 AM
To: Chris Metcalf
Cc: Vincent JARDIN; Bruce Richardson; Jerin Jacob; Olivier Matz; Liming Sun; Olga Shern; Yael Shenhav; dev@dpdk.org
Subject: Re: [PATCH 0/4] catch up TILE-Gx support in DPDK

2017-02-17 20:52, Chris Metcalf:
> This patch series allows DPDK to build for TILE-Gx as of version 17.02.
> 
> A required library (libgxio) had not been made publicly available.
> It is now available as source here:
> 
>   
> http://www.mellanox.com/repository/solutions/tile-scm/libgxio-1.0.tar.
> xz
> 
> it has also been folded into the binary release of the generic 
> toolchain that we periodically update on that website; for more 
> information about the toolchain tarballs, see here:
> 
>   http://www.mellanox.com/repository/solutions/tile-scm/
> 
> Note that the toolchain components were updated slightly in this 
> release of the tarballs relative to what was there before.

Thank you.
Some of these changes (being able to compile on a free toolchain) should have been done since the beginning. Better later than never :) I think we won't allow any new component in DPDK which cannot be built freely, in the future (lessons learned).

> Hopefully, with DPDK now working on TILE-Gx again, there may be 
> interest from someone in the community in taking on a maintenance 
> role.  At this point, the Mellanox engineering team responsible for 
> TILE-Gx is largely focused on working on future chips based on ARMv8, 
> so unfortunately we won't have much bandwidth for TILE-Gx support going forward.

So do you mean that the TILE-Gx maintainers officially give up on their role?
Then please update the MAINTAINERS file.

> If it still seems like removal makes sense now or at some point in the 
> future, it would probably at least be good to apply these patches so 
> there is a baseline to pick it up from later.

I agree. We can apply these patches before removing the whole architecture.

> Liming Sun, the tile dpdk maintainer, has reviewed these changes (he 
> sits next to me); if it's more appropriate, he can resend these 
> changes with his Signed-off-by as well.  I took on this work since I 
> was more familiar with libgxio and the details of our toolchain (I am 
> the maintainer for the tile architecture for Linux and glibc).

I think it is OK as is.

Re: [PATCH 0/4] catch up TILE-Gx support in DPDK

[Chris Metcalf]

Lining please go ahead since you are the maintainer. Note I adjusted maintainers in my patch so probably best to wait for that series to be applied then just remove the maintainers entry along with all the tilegx mpipe stuff. 

Sent from the waterpark while waiting for a kid :)

On Feb 21, 2017, at 10:54 AM, Liming Sun <lsun@mellanox.com> wrote:

>>> So do you mean that the TILE-Gx maintainers officially give up on their role?
>>> Then please update the MAINTAINERS file.
> 
> Yes. Please update the MAINTAINERS file as needed.
> Chris Metcalf is out this week. I could submit a separate patch for the MAINTAINERS file if it's required. Or we could wait a little bit until Chris comes back.
> 
> Thanks,
> Liming
> 
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] 
> Sent: Saturday, February 18, 2017 4:30 AM
> To: Chris Metcalf
> Cc: Vincent JARDIN; Bruce Richardson; Jerin Jacob; Olivier Matz; Liming Sun; Olga Shern; Yael Shenhav; dev@dpdk.org
> Subject: Re: [PATCH 0/4] catch up TILE-Gx support in DPDK
> 
> 2017-02-17 20:52, Chris Metcalf:
>> This patch series allows DPDK to build for TILE-Gx as of version 17.02.
>> 
>> A required library (libgxio) had not been made publicly available.
>> It is now available as source here:
>> 
>> 
>> http://www.mellanox.com/repository/solutions/tile-scm/libgxio-1.0.tar.
>> xz
>> 
>> it has also been folded into the binary release of the generic 
>> toolchain that we periodically update on that website; for more 
>> information about the toolchain tarballs, see here:
>> 
>>  http://www.mellanox.com/repository/solutions/tile-scm/
>> 
>> Note that the toolchain components were updated slightly in this 
>> release of the tarballs relative to what was there before.
> 
> Thank you.
> Some of these changes (being able to compile on a free toolchain) should have been done since the beginning. Better later than never :) I think we won't allow any new component in DPDK which cannot be built freely, in the future (lessons learned).
> 
>> Hopefully, with DPDK now working on TILE-Gx again, there may be 
>> interest from someone in the community in taking on a maintenance 
>> role.  At this point, the Mellanox engineering team responsible for 
>> TILE-Gx is largely focused on working on future chips based on ARMv8, 
>> so unfortunately we won't have much bandwidth for TILE-Gx support going forward.
> 
> So do you mean that the TILE-Gx maintainers officially give up on their role?
> Then please update the MAINTAINERS file.
> 
>> If it still seems like removal makes sense now or at some point in the 
>> future, it would probably at least be good to apply these patches so 
>> there is a baseline to pick it up from later.
> 
> I agree. We can apply these patches before removing the whole architecture.
> 
>> Liming Sun, the tile dpdk maintainer, has reviewed these changes (he 
>> sits next to me); if it's more appropriate, he can resend these 
>> changes with his Signed-off-by as well.  I took on this work since I 
>> was more familiar with libgxio and the details of our toolchain (I am 
>> the maintainer for the tile architecture for Linux and glibc).
> 
> I think it is OK as is.
> 

Re: [PATCH 0/4] catch up TILE-Gx support in DPDK

[Thomas Monjalon]

2017-02-17 20:52, Chris Metcalf:
> This patch series allows DPDK to build for TILE-Gx as of version 17.02.
> 
> A required library (libgxio) had not been made publicly available.
> It is now available as source here:
> 
>   http://www.mellanox.com/repository/solutions/tile-scm/libgxio-1.0.tar.xz
> 
> it has also been folded into the binary release of the generic
> toolchain that we periodically update on that website; for more
> information about the toolchain tarballs, see here:
> 
>   http://www.mellanox.com/repository/solutions/tile-scm/
> 
> Note that the toolchain components were updated slightly in this release
> of the tarballs relative to what was there before.
> 
> Hopefully, with DPDK now working on TILE-Gx again, there may be interest
> from someone in the community in taking on a maintenance role.  At this
> point, the Mellanox engineering team responsible for TILE-Gx is largely
> focused on working on future chips based on ARMv8, so unfortunately we
> won't have much bandwidth for TILE-Gx support going forward.
> 
> If it still seems like removal makes sense now or at some point in the
> future, it would probably at least be good to apply these patches so
> there is a baseline to pick it up from later.
> 
> Liming Sun, the tile dpdk maintainer, has reviewed these changes (he
> sits next to me); if it's more appropriate, he can resend these changes
> with his Signed-off-by as well.  I took on this work since I was more
> familiar with libgxio and the details of our toolchain (I am the
> maintainer for the tile architecture for Linux and glibc).
> 
> Chris Metcalf (4):
>   tile: avoid use of non-upstreamed <arch/cycle.h>
>   tile: remove requirement for <arch/mpipe_{xaui,gbe}_def.h headers
>   strict alignment: generalize warning handling
>   tile: fix remaining build issues

Applied, thanks

Next step is to remove the code for tile and mpipe, as agreed.