I saw two new build errors with invalid configurations on mlx5e, and a
closer look revealed that one of them was caused by a slightly incorrect
fix for which I had sent a different patch when it first broke.
This series reverts the new fix for the VXLAN problem as it caused
another bug, and follows up with a new version of my patch (adapted
as originally requested), and another patch for the simiar RFS
bug that was just introduced.
Arnd
This reverts commit 69976fb1045850a742deb9790ea49cbc6f497531.
We cannot select VXLAN when IPv4 support is disabled, that just gives
us additional build errors, including:
warning: (MLX5_CORE_EN) selects VXLAN which has unmet direct dependencies (NETDEVICES && NET_CORE && INET)
In file included from ../drivers/net/vxlan.c:36:0:
include/net/udp_tunnel.h: In function 'udp_tunnel_handle_offloads':
include/net/udp_tunnel.h:112:9: error: implicit declaration of function 'iptunnel_handle_offloads' [-Werror=implicit-function-declaration]
return iptunnel_handle_offloads(skb, type);
^~~~~~~~~~~~~~~~~~~~~~~~
I'm sending a proper fix for the original bug in a separate patch.
Signed-off-by: Arnd Bergmann <redacted>
---
drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 1 -
1 file changed, 1 deletion(-)
--
2.7.0
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
VXLAN can be disabled at compile-time or it can be a loadable
module while mlx5 is built-in, which leads to a link error:
drivers/net/built-in.o: In function `mlx5e_create_netdev':
ntb_netdev.c:(.text+0x106de4): undefined reference to `vxlan_get_rx_port'
This avoids the link error and makes the vxlan code optional,
like the other ethernet drivers do as well.
Signed-off-by: Arnd Bergmann <redacted>
Link: https://patchwork.ozlabs.org/patch/589296/
Fixes: b3f63c3d5e2c ("net/mlx5e: Add netdev support for VXLAN tunneling")
---
I sent it originally on Feb 26 2016, but misread Saeed Mahameed's
reply as saying that he'd fix it up himself. The new version
should address the original comment.
---
drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 7 +++++++
drivers/net/ethernet/mellanox/mlx5/core/Makefile | 4 +++-
drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 ++
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 4 ++++
drivers/net/ethernet/mellanox/mlx5/core/vxlan.h | 11 +++++++++--
5 files changed, 25 insertions(+), 3 deletions(-)
--
2.7.0
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
The RFS acceleration support in mlx5 is enabled whenever CONFIG_RFS_ACCEL
is in use. However, this fails if a user turns off CONFIG_MLX5_CORE_EN,
because the rfs code now calls into the ethernet portion of the
driver:
ERROR: "mlx5e_destroy_flow_table" [drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko] undefined!
This patch adds another Kconfig symbol to control the compilation of
the RFS code, to ensure it is only built if both the ethernet support
and the core RFS support are enabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 4 ++++
drivers/net/ethernet/mellanox/mlx5/core/Makefile | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
On Wed, May 4, 2016 at 3:32 PM, Arnd Bergmann [off-list ref] wrote:
The RFS acceleration support in mlx5 is enabled whenever CONFIG_RFS_ACCEL
is in use. However, this fails if a user turns off CONFIG_MLX5_CORE_EN,
because the rfs code now calls into the ethernet portion of the
driver:
ERROR: "mlx5e_destroy_flow_table" [drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko] undefined!
Hi Arnd,
We already posted a fix for this, please see "[PATCH net-next V1
01/12] net/mlx5e: Fix aRFS compilation dependency", and give us your
feedback.
Saeed.
On Wednesday 04 May 2016 16:09:16 Saeed Mahameed wrote:
On Wed, May 4, 2016 at 3:32 PM, Arnd Bergmann [off-list ref] wrote:
quoted
The RFS acceleration support in mlx5 is enabled whenever CONFIG_RFS_ACCEL
is in use. However, this fails if a user turns off CONFIG_MLX5_CORE_EN,
because the rfs code now calls into the ethernet portion of the
driver:
ERROR: "mlx5e_destroy_flow_table" [drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko] undefined!
Hi Arnd,
We already posted a fix for this, please see "[PATCH net-next V1
01/12] net/mlx5e: Fix aRFS compilation dependency", and give us your
feedback.
That version looks fine as well. I think it's better to be a little
more explicit as I was, but either way seems fine.
You can also achieve the same thing in yet another way using Makefile
syntax instead of cpp or Kconfig:
ifdef CONFIG_MLX5_CORE_EN
mlx5_core-y += wq.o eswitch.o \
en_main.o en_fs.o en_ethtool.o en_tx.o en_rx.o \
en_txrx.o en_clock.o vxlan.o en_tc.o
en_txrx.o en_clock.o vxlan.o en_tc.o en_arfs.o
mlx5_core-$(CONFIG_RFS_ACCEL) += en_arfs.o
endif
If you prefer Maor's version, feel free to add
Acked-by: Arnd Bergmann <arnd@arndb.de>
Arnd
On Wed, May 4, 2016 at 5:23 PM, Arnd Bergmann [off-list ref] wrote:
On Wednesday 04 May 2016 16:09:16 Saeed Mahameed wrote:
quoted
On Wed, May 4, 2016 at 3:32 PM, Arnd Bergmann [off-list ref] wrote:
quoted
The RFS acceleration support in mlx5 is enabled whenever CONFIG_RFS_ACCEL
is in use. However, this fails if a user turns off CONFIG_MLX5_CORE_EN,
because the rfs code now calls into the ethernet portion of the
driver:
ERROR: "mlx5e_destroy_flow_table" [drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko] undefined!
Hi Arnd,
We already posted a fix for this, please see "[PATCH net-next V1
01/12] net/mlx5e: Fix aRFS compilation dependency", and give us your
feedback.
That version looks fine as well. I think it's better to be a little
more explicit as I was, but either way seems fine.
Simply we didn't want to add new Kconfig flag.
You can also achieve the same thing in yet another way using Makefile
syntax instead of cpp or Kconfig:
ifdef CONFIG_MLX5_CORE_EN
mlx5_core-y += wq.o eswitch.o \
en_main.o en_fs.o en_ethtool.o en_tx.o en_rx.o \
en_txrx.o en_clock.o vxlan.o en_tc.o
en_txrx.o en_clock.o vxlan.o en_tc.o en_arfs.o
mlx5_core-$(CONFIG_RFS_ACCEL) += en_arfs.o
endif
If you prefer Maor's version, feel free to add
Acked-by: Arnd Bergmann <redacted>
I do prefer this version, but the difference is small, so will keep Maor's.
Thanks Arnd for the Ack and the suggestion.
Saeed.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, May 4, 2016 at 3:31 PM, Arnd Bergmann [off-list ref] wrote:
VXLAN can be disabled at compile-time or it can be a loadable
module while mlx5 is built-in, which leads to a link error:
drivers/net/built-in.o: In function `mlx5e_create_netdev':
ntb_netdev.c:(.text+0x106de4): undefined reference to `vxlan_get_rx_port'
This avoids the link error and makes the vxlan code optional,
like the other ethernet drivers do as well.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patchwork.ozlabs.org/patch/589296/
Fixes: b3f63c3d5e2c ("net/mlx5e: Add netdev support for VXLAN tunneling")
---
I sent it originally on Feb 26 2016, but misread Saeed Mahameed's
reply as saying that he'd fix it up himself. The new version
should address the original comment.
---
Hi Arnd,
I didn't post a fix up since it is not needed anymore, see
b7aade15485a ('vxlan: break dependency with netdev drivers') in
net-next.
The new issue is introduced due to : "net/mlx5: Kconfig: Fix
MLX5_EN/VXLAN build issue" which was merged from net tree.
Dave shouldn't have merged it into net-next, I explicitly asked him
that in the cover letter. Maybe he missed it.
I just checked and It is sufficient to only take the revert patch:
[PATCH 1/3] Revert "net/mlx5: Kconfig: Fix MLX5_EN/VXLAN build issue"
to net-next.
Can you please confirm that with only the revert patch, you don't see
the issue ?
On Thursday 05 May 2016 19:44:36 Saeed Mahameed wrote:
On Wed, May 4, 2016 at 3:31 PM, Arnd Bergmann [off-list ref] wrote:
quoted
VXLAN can be disabled at compile-time or it can be a loadable
module while mlx5 is built-in, which leads to a link error:
drivers/net/built-in.o: In function `mlx5e_create_netdev':
ntb_netdev.c:(.text+0x106de4): undefined reference to `vxlan_get_rx_port'
This avoids the link error and makes the vxlan code optional,
like the other ethernet drivers do as well.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patchwork.ozlabs.org/patch/589296/
Fixes: b3f63c3d5e2c ("net/mlx5e: Add netdev support for VXLAN tunneling")
---
I sent it originally on Feb 26 2016, but misread Saeed Mahameed's
reply as saying that he'd fix it up himself. The new version
should address the original comment.
---
Hi Arnd,
I didn't post a fix up since it is not needed anymore, see
b7aade15485a ('vxlan: break dependency with netdev drivers') in
net-next.
The new issue is introduced due to : "net/mlx5: Kconfig: Fix
MLX5_EN/VXLAN build issue" which was merged from net tree.
Dave shouldn't have merged it into net-next, I explicitly asked him
that in the cover letter. Maybe he missed it.
I just checked and It is sufficient to only take the revert patch:
[PATCH 1/3] Revert "net/mlx5: Kconfig: Fix MLX5_EN/VXLAN build issue"
to net-next.
Can you please confirm that with only the revert patch, you don't see
the issue ?
Yes, it works, but not it is different from all the other drivers
(MLX4, BENET, IXGBE, I40E, FM10K, QLCNIC, and QEDE). If the 'select
VXLAN' is not the preferred way to handle this, we should change
the other ones the same way, right?
For reference, I've tried it out on the MLX4 driver, and it does
seem nicer that way, see below.
Arnd
---
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
in case someone wants to pick up that patch and do the other
ones as well.
For reference, I've tried it out on the MLX4 driver, and it does
seem nicer that way, see below.
Is it possible to wind down this conversation and have someone submit
whatever final patch everyone agrees to?
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Alexander Duyck <hidden> Date: 2016-05-06 20:12:52
On Thu, May 5, 2016 at 11:09 AM, Arnd Bergmann [off-list ref] wrote:
quoted hunk
On Thursday 05 May 2016 19:44:36 Saeed Mahameed wrote:
quoted
On Wed, May 4, 2016 at 3:31 PM, Arnd Bergmann [off-list ref] wrote:
quoted
VXLAN can be disabled at compile-time or it can be a loadable
module while mlx5 is built-in, which leads to a link error:
drivers/net/built-in.o: In function `mlx5e_create_netdev':
ntb_netdev.c:(.text+0x106de4): undefined reference to `vxlan_get_rx_port'
This avoids the link error and makes the vxlan code optional,
like the other ethernet drivers do as well.
Signed-off-by: Arnd Bergmann <redacted>
Link: https://patchwork.ozlabs.org/patch/589296/
Fixes: b3f63c3d5e2c ("net/mlx5e: Add netdev support for VXLAN tunneling")
---
I sent it originally on Feb 26 2016, but misread Saeed Mahameed's
reply as saying that he'd fix it up himself. The new version
should address the original comment.
---
Hi Arnd,
I didn't post a fix up since it is not needed anymore, see
b7aade15485a ('vxlan: break dependency with netdev drivers') in
net-next.
The new issue is introduced due to : "net/mlx5: Kconfig: Fix
MLX5_EN/VXLAN build issue" which was merged from net tree.
Dave shouldn't have merged it into net-next, I explicitly asked him
that in the cover letter. Maybe he missed it.
I just checked and It is sufficient to only take the revert patch:
[PATCH 1/3] Revert "net/mlx5: Kconfig: Fix MLX5_EN/VXLAN build issue"
to net-next.
Can you please confirm that with only the revert patch, you don't see
the issue ?
Yes, it works, but not it is different from all the other drivers
(MLX4, BENET, IXGBE, I40E, FM10K, QLCNIC, and QEDE). If the 'select
VXLAN' is not the preferred way to handle this, we should change
the other ones the same way, right?
For reference, I've tried it out on the MLX4 driver, and it does
seem nicer that way, see below.
Arnd
---
Signed-off-by: Arnd Bergmann <redacted>
in case someone wants to pick up that patch and do the other
ones as well.
This piece is unnecessary and unwanted. We just recently added the
ability to load the modules without the need for VXLAN. Lets not take
that in the wrong direction by having the drivers select a module they
don't have to have.
The rest of this code is probably fine. After the dependency was
broken via b7aade15485a ('vxlan: break dependency with netdev
drivers') you could probably go through and just pull all the VXLAN
ifdefs from all the drivers since I don't think there is anything that
explicitly relies on that module anymore as the only export still
hanging around is vxlan_dev_create and I don't think any Ethernet
drivers are directly spawning VXLAN interfaces.
quoted hunk
@@ -24,13 +25,6 @@ config MLX4_EN_DCB If unsure, set to Y-config MLX4_EN_VXLAN- bool "VXLAN offloads Support"- default y- depends on MLX4_EN && VXLAN && !(MLX4_EN=y && VXLAN=m)- ---help---- Say Y here if you want to use VXLAN offloads in the driver.- config MLX4_CORE tristate depends on PCI
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
For reference, I've tried it out on the MLX4 driver, and it does
seem nicer that way, see below.
Is it possible to wind down this conversation and have someone submit
whatever final patch everyone agrees to?
Yes, Just reposted to net what Arnd originally posted to net-next.
"[PATCH net 0/2] net/mlx5e: Kconfig fixes for VxLAN"
[...]
Arnd Bergmann (2):
Revert "net/mlx5: Kconfig: Fix MLX5_EN/VXLAN build issue"
net/mlx5e: make VXLAN support conditional
I just rebased the patches on top of net.
Arnd please have a look.
Thanks,
Saeed.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
For reference, I've tried it out on the MLX4 driver, and it does
seem nicer that way, see below.
Is it possible to wind down this conversation and have someone submit
whatever final patch everyone agrees to?
Yes, Just reposted to net what Arnd originally posted to net-next.
"[PATCH net 0/2] net/mlx5e: Kconfig fixes for VxLAN"
[...]
Arnd Bergmann (2):
Revert "net/mlx5: Kconfig: Fix MLX5_EN/VXLAN build issue"
net/mlx5e: make VXLAN support conditional
I just rebased the patches on top of net.
Arnd please have a look.
Sorry for the delay, it looks all fine now and I see no more warnings.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html