From: Jakub Kicinski <jakub.kicinski@netronome•com>
To: Mark Brown <broonie@kernel•org>
Cc: David Miller <davem@davemloft•net>,
Networking <netdev@vger•kernel.org>,
Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome•com>,
Linux-Next Mailing List <linux-next@vger•kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger•kernel.org>
Subject: Re: linux-next: manual merge of the net-next tree with Linus' tree
Date: Mon, 30 Oct 2017 10:43:07 -0700 [thread overview]
Message-ID: <20171030104307.0857ee38@cakuba.netronome.com> (raw)
In-Reply-To: <20171030170224.badokg3dsgjb4hvg@sirena.co.uk>
On Mon, 30 Oct 2017 17:02:24 +0000, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/ethernet/netronome/nfp/flower/action.c
>
> between commit:
>
> d309ae5c6a0064 ("nfp: refuse offloading filters that redirects to upper devices")
>
> from Linus' tree and commit:
>
> 62d3f60b4d065c ("nfp: use struct fields for 8 bit-wide access")
Actually the conflict is with a much older commit b27d6a95a70d ("nfp:
compile flower vxlan tunnel set actions").
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Unfortunately, this is not a correct resolution. Please see below.
> diff --cc drivers/net/ethernet/netronome/nfp/flower/action.c
> index 8ea9320014ee,0a5fc9f8545f..000000000000
> --- a/drivers/net/ethernet/netronome/nfp/flower/action.c
> +++ b/drivers/net/ethernet/netronome/nfp/flower/action.c
> @@@ -105,19 -104,326 +104,329 @@@ nfp_fl_output(struct nfp_fl_output *out
> if (!out_dev)
> return -EOPNOTSUPP;
>
> - /* Only offload egress ports are on the same device as the ingress
> - * port.
> + tmp_flags = last ? NFP_FL_OUT_FLAGS_LAST : 0;
> +
> + if (tun_type) {
> + /* Verify the egress netdev matches the tunnel type. */
> + if (!nfp_fl_netdev_is_tunnel_type(out_dev, tun_type))
> + return -EOPNOTSUPP;
> +
> + if (*tun_out_cnt)
> + return -EOPNOTSUPP;
> + (*tun_out_cnt)++;
> +
> + output->flags = cpu_to_be16(tmp_flags |
> + NFP_FL_OUT_FLAGS_USE_TUN);
> + output->port = cpu_to_be32(NFP_FL_PORT_TYPE_TUN | tun_type);
> + } else {
> + /* Set action output parameters. */
> + output->flags = cpu_to_be16(tmp_flags);
> +
> + /* Only offload if egress ports are on the same device as the
> + * ingress port.
> + */
> + if (!switchdev_port_same_parent_id(in_dev, out_dev))
> + return -EOPNOTSUPP;
The code from net should be inserted here. Note that net-next only
indented this area, the code is unchanged.
if (!nfp_netdev_is_nfp_repr(out_dev))
return -EOPNOTSUPP;
should immediately follow switchdev_port_same_parent_id() check.
> + output->port = cpu_to_be32(nfp_repr_get_port_id(out_dev));
> + if (!output->port)
> + return -EOPNOTSUPP;
> + }
> + nfp_flow->meta.shortcut = output->port;
> +
> + return 0;
> + }
> +
> + static bool nfp_fl_supported_tun_port(const struct tc_action *action)
> + {
> + struct ip_tunnel_info *tun = tcf_tunnel_info(action);
> +
> + return tun->key.tp_dst == htons(NFP_FL_VXLAN_PORT);
> + }
> +
> + static struct nfp_fl_pre_tunnel *nfp_fl_pre_tunnel(char *act_data, int act_len)
> + {
> + size_t act_size = sizeof(struct nfp_fl_pre_tunnel);
> + struct nfp_fl_pre_tunnel *pre_tun_act;
> +
> + /* Pre_tunnel action must be first on action list.
> + * If other actions already exist they need pushed forward.
> */
> - if (!switchdev_port_same_parent_id(in_dev, out_dev))
> + if (act_len)
> + memmove(act_data + act_size, act_data, act_len);
> +
> + pre_tun_act = (struct nfp_fl_pre_tunnel *)act_data;
> +
> + memset(pre_tun_act, 0, act_size);
> +
> + pre_tun_act->head.jump_id = NFP_FL_ACTION_OPCODE_PRE_TUNNEL;
> + pre_tun_act->head.len_lw = act_size >> NFP_FL_LW_SIZ;
> +
> + return pre_tun_act;
> + }
> +
> + static int
> + nfp_fl_set_vxlan(struct nfp_fl_set_vxlan *set_vxlan,
> + const struct tc_action *action,
> + struct nfp_fl_pre_tunnel *pre_tun)
> + {
> + struct ip_tunnel_info *vxlan = tcf_tunnel_info(action);
> + size_t act_size = sizeof(struct nfp_fl_set_vxlan);
> + u32 tmp_set_vxlan_type_index = 0;
> + /* Currently support one pre-tunnel so index is always 0. */
> + int pretun_idx = 0;
> +
> + if (vxlan->options_len) {
> + /* Do not support options e.g. vxlan gpe. */
> return -EOPNOTSUPP;
> + }
> +
> + if (!nfp_netdev_is_nfp_repr(out_dev))
> + return -EOPNOTSUPP;
> +
> - output->port = cpu_to_be32(nfp_repr_get_port_id(out_dev));
> - if (!output->port)
> + set_vxlan->head.jump_id = NFP_FL_ACTION_OPCODE_SET_IPV4_TUNNEL;
> + set_vxlan->head.len_lw = act_size >> NFP_FL_LW_SIZ;
> +
> + /* Set tunnel type and pre-tunnel index. */
> + tmp_set_vxlan_type_index |=
> + FIELD_PREP(NFP_FL_IPV4_TUNNEL_TYPE, NFP_FL_TUNNEL_VXLAN) |
> + FIELD_PREP(NFP_FL_IPV4_PRE_TUN_INDEX, pretun_idx);
next prev parent reply other threads:[~2017-10-30 17:43 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-30 17:02 linux-next: manual merge of the net-next tree with Linus' tree Mark Brown
2017-10-30 17:43 ` Jakub Kicinski [this message]
2017-10-30 18:10 ` Mark Brown
-- strict thread matches above, loose matches on Subject: below --
2024-10-18 1:00 Stephen Rothwell
2023-12-14 23:52 Stephen Rothwell
2023-02-16 23:40 Stephen Rothwell
2023-02-16 23:18 Stephen Rothwell
2022-10-27 23:28 Stephen Rothwell
2022-10-28 6:53 ` Marc Kleine-Budde
2022-09-21 1:00 Stephen Rothwell
2022-09-21 4:40 ` Colin Foster
2022-07-15 2:01 Stephen Rothwell
2022-07-15 1:48 Stephen Rothwell
2021-07-23 2:32 Stephen Rothwell
2021-01-29 0:59 Stephen Rothwell
2021-01-29 0:48 Stephen Rothwell
2021-01-29 0:43 Stephen Rothwell
2019-10-21 0:07 Stephen Rothwell
2019-09-15 20:31 Mark Brown
2019-09-15 20:24 Mark Brown
2019-06-17 1:44 Stephen Rothwell
2019-06-04 0:30 Stephen Rothwell
2019-06-04 0:29 Stephen Rothwell
2019-04-02 22:56 Stephen Rothwell
2018-07-20 1:49 Stephen Rothwell
2018-06-06 4:37 Stephen Rothwell
2017-12-04 22:59 Stephen Rothwell
2017-11-09 23:31 Stephen Rothwell
2017-11-10 4:37 ` Cong Wang
2017-11-10 4:39 ` David Miller
2017-10-30 17:24 Mark Brown
2017-10-30 17:08 Mark Brown
2017-06-30 0:57 Stephen Rothwell
2017-05-03 1:07 Stephen Rothwell
2017-05-03 4:08 ` David Miller
2017-03-24 0:05 Stephen Rothwell
2017-03-24 0:10 ` David Miller
2017-03-24 1:24 ` Alexei Starovoitov
2017-02-02 1:49 Stephen Rothwell
2017-02-02 8:40 ` Yotam Gigi
2016-10-02 22:37 Stephen Rothwell
2016-10-02 22:32 Stephen Rothwell
2016-06-30 1:01 Stephen Rothwell
2016-05-03 3:15 Stephen Rothwell
2016-03-15 0:07 Stephen Rothwell
2016-03-15 8:53 ` Gregory CLEMENT
2015-07-14 1:46 Stephen Rothwell
2015-07-14 8:23 ` Nikolay Aleksandrov
2015-05-28 4:17 Stephen Rothwell
2015-05-28 13:34 ` Tom Lendacky
2015-02-12 1:05 Stephen Rothwell
2014-06-12 2:01 Stephen Rothwell
2014-06-05 3:13 Stephen Rothwell
2014-06-05 3:26 ` KY Srinivasan
2013-12-18 1:46 Stephen Rothwell
2013-12-18 1:56 ` Jeff Kirsher
2013-12-18 2:19 ` Stephen Rothwell
2013-09-05 5:23 Stephen Rothwell
2013-09-05 5:19 Stephen Rothwell
2013-09-05 7:33 ` Daniel Borkmann
2013-09-02 3:12 Stephen Rothwell
2013-06-17 2:44 Stephen Rothwell
2013-06-17 2:38 Stephen Rothwell
2013-04-22 3:09 Stephen Rothwell
2013-04-23 0:42 ` David Miller
2013-04-22 3:03 Stephen Rothwell
2013-04-23 0:41 ` David Miller
2013-04-22 2:48 Stephen Rothwell
2013-04-22 2:43 Stephen Rothwell
2013-04-23 0:41 ` David Miller
2013-03-27 0:57 Stephen Rothwell
2013-03-27 4:54 ` David Miller
2013-03-12 0:33 Stephen Rothwell
2013-03-12 10:49 ` David Miller
2012-11-08 23:53 Stephen Rothwell
2012-11-10 23:34 ` David Miller
2012-10-02 1:51 Stephen Rothwell
2012-09-26 1:46 Stephen Rothwell
2012-07-19 1:15 Stephen Rothwell
2012-07-19 1:18 ` Jeff Kirsher
2012-02-27 1:11 Stephen Rothwell
2012-02-27 4:05 ` David Miller
2012-02-29 3:21 ` Ben Hutchings
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171030104307.0857ee38@cakuba.netronome.com \
--to=jakub.kicinski@netronome$(echo .)com \
--cc=broonie@kernel$(echo .)org \
--cc=davem@davemloft$(echo .)net \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pieter.jansenvanvuuren@netronome$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox