Intel-Wired-Lan Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Marcin Szycik <marcin.szycik@linux.intel.com>
To: Simon Horman <simon.horman@corigine.com>, alexandr.lobakin@intel.com
Cc: jiri@resnulli.us, netdev@vger.kernel.org, idosch@nvidia.com,
	jesse.brandeburg@intel.com, intel-wired-lan@lists.osuosl.org,
	kuba@kernel.org, pabeni@redhat.com, davem@davemloft.net
Subject: Re: [Intel-wired-lan] [RFC PATCH iwl-next 2/6] ip_tunnel: convert __be16 tunnel flags to bitmaps
Date: Mon, 5 Jun 2023 16:21:52 +0200	[thread overview]
Message-ID: <98021ae6-cbe4-d0a6-630e-27ae44383376@linux.intel.com> (raw)
In-Reply-To: <ZH2plrPDtUdmjL7w@corigine.com>

On 05.06.2023 11:23, Simon Horman wrote:
> On Thu, Jun 01, 2023 at 03:19:25PM +0200, Marcin Szycik wrote:
>> From: Alexander Lobakin <alexandr.lobakin@intel.com>
>>
>> Historically, tunnel flags like TUNNEL_CSUM or TUNNEL_ERSPAN_OPT
>> have been defined as __be16. Now all of those 16 bits are occupied
>> and there's no more free space for new flags.
>> It can't be simply switched to a bigger container with no
>> adjustments to the values, since it's an explicit Endian storage,
>> and on LE systems (__be16)0x0001 equals to
>> (__be64)0x0001000000000000.
>> We could probably define new 64-bit flags depending on the
>> Endianness, i.e. (__be64)0x0001 on BE and (__be64)0x00010000... on
>> LE, but that would introduce an Endianness dependency and spawn a
>> ton of Sparse warnings. To mitigate them, all of those places which
>> were adjusted with this change would be touched anyway, so why not
>> define stuff properly if there's no choice.
> 
> Hi Marcin,
> 
> a few nits from my side, that you can take or leave.
> Overall this looks good to me.
> 
> 
> Reviewed-by: Simon Horman <simon.horman@corigine.com>

Hi Simon,

Thank you for review, I will fix the minor issues in v2.

> 
>> Define IP_TUNNEL_*_BIT counterparts as a bit number instead of the
>> value already coded and a fistful of <16 <-> bitmap> converters and
>> helpers. The two flags which have a different bit position are
>> SIT_ISATAP_64 and VTI_ISVTI_64, as they were defined not as
>> __cpu_to_be16(), but as (__force __be16), i.e. had different
>> positions on LE and BE. Now they have a strongly defined place.
>> Change all __be16 fields which were used to store those flags, to
>> IP_TUNNEL_DECLARE_FLAGS() -> DECLARE_BITMAP(__IP_TUNNEL_FLAG_NUM) ->
>> unsigned long[1] for now, and replace all TUNNEL_* occurencies to
>> their 64-bit bitmap counterparts. Use the converters in the places
>> which talk to the userspace, hardware (NFP) or other hosts (GRE
>> header). The rest must explicitly use the new flags only. This must
>> be done at once, otherwise there will be too much conversions
>> throughout the code in the intermediate commits.
>> Finally, disable the old __be16 flags for use in the kernel code
>> (except for the two 'irregular' flags mentioned above), to prevent
>> any accidential (mis)use of them. For the userspace, nothing is
> 
> nit: s/accidential/accidental/
> 
>> changed, only additions were made.
>>
>> Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
>> Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com>
> 
>> ---
>>  drivers/net/bareudp.c                         |  19 ++-
>>  .../ethernet/mellanox/mlx5/core/en/tc_tun.h   |   2 +-
>>  .../mellanox/mlx5/core/en/tc_tun_encap.c      |   6 +-
>>  .../mellanox/mlx5/core/en/tc_tun_geneve.c     |  12 +-
>>  .../mellanox/mlx5/core/en/tc_tun_gre.c        |   9 +-
>>  .../mellanox/mlx5/core/en/tc_tun_vxlan.c      |   9 +-
>>  .../net/ethernet/mellanox/mlx5/core/en_tc.c   |  15 +-
>>  .../ethernet/mellanox/mlxsw/spectrum_ipip.c   |  32 +++--
>>  .../ethernet/mellanox/mlxsw/spectrum_span.c   |   6 +-
>>  .../ethernet/netronome/nfp/flower/action.c    |  26 +++-
>>  drivers/net/geneve.c                          |  46 +++---
>>  drivers/net/vxlan/vxlan_core.c                |  14 +-
>>  include/net/dst_metadata.h                    |  10 +-
>>  include/net/flow_dissector.h                  |   2 +-
>>  include/net/gre.h                             |  59 ++++----
>>  include/net/ip6_tunnel.h                      |   4 +-
>>  include/net/ip_tunnels.h                      |  90 ++++++++++--
>>  include/net/udp_tunnel.h                      |   4 +-
>>  include/uapi/linux/if_tunnel.h                |  33 +++++
>>  net/bridge/br_vlan_tunnel.c                   |   5 +-
>>  net/core/filter.c                             |  20 +--
>>  net/core/flow_dissector.c                     |  12 +-
>>  net/ipv4/fou_bpf.c                            |   2 +-
>>  net/ipv4/gre_demux.c                          |   2 +-
>>  net/ipv4/ip_gre.c                             | 131 +++++++++++-------
>>  net/ipv4/ip_tunnel.c                          |  51 ++++---
>>  net/ipv4/ip_tunnel_core.c                     |  81 +++++++----
>>  net/ipv4/ip_vti.c                             |  31 +++--
>>  net/ipv4/ipip.c                               |  21 ++-
>>  net/ipv4/udp_tunnel_core.c                    |   5 +-
>>  net/ipv6/ip6_gre.c                            |  87 +++++++-----
>>  net/ipv6/ip6_tunnel.c                         |  14 +-
>>  net/ipv6/sit.c                                |   9 +-
>>  net/netfilter/ipvs/ip_vs_core.c               |   6 +-
>>  net/netfilter/ipvs/ip_vs_xmit.c               |  20 +--
>>  net/netfilter/nft_tunnel.c                    |  45 +++---
>>  net/openvswitch/flow_netlink.c                |  55 ++++----
>>  net/psample/psample.c                         |  26 ++--
>>  net/sched/act_tunnel_key.c                    |  39 +++---
>>  net/sched/cls_flower.c                        |  27 ++--
>>  40 files changed, 695 insertions(+), 392 deletions(-)
> 
> nit: this is a rather long patch

Yes, but most of it comes from the fact that tunnel flags are simply used
in many places, and we need to touch all of them.

Alex, do you see a way to logically split this patch into smaller ones?

> 
> ...
> 
>> diff --git a/include/uapi/linux/if_tunnel.h b/include/uapi/linux/if_tunnel.h
>> index 102119628ff5..d222e70d8621 100644
>> --- a/include/uapi/linux/if_tunnel.h
>> +++ b/include/uapi/linux/if_tunnel.h
>> @@ -161,6 +161,14 @@ enum {
>>  
>>  #define IFLA_VTI_MAX	(__IFLA_VTI_MAX - 1)
>>  
>> +#ifndef __KERNEL__
>> +/* Historically, tunnel flags have been defined as __be16 and now there are
>> + * no free bits left. It is strongly advised to switch the already existing
>> + * userspace code to u32/BIGINT and the new *_BIT definitions from down below,
>> + * as __be16 can't be simply casted to a wider type on LE systems. All new
> 
> nit: s/casted/cast/
> 
> ...
> 
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

  reply	other threads:[~2023-06-05 14:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-01 13:19 [Intel-wired-lan] [RFC PATCH iwl-next 0/6] ice: Add PFCP filter support Marcin Szycik
2023-06-01 13:19 ` [Intel-wired-lan] [RFC PATCH iwl-next 1/6] ip_tunnel: use a separate struct to store tunnel params in the kernel Marcin Szycik
2023-06-05  9:23   ` Simon Horman
2023-06-01 13:19 ` [Intel-wired-lan] [RFC PATCH iwl-next 2/6] ip_tunnel: convert __be16 tunnel flags to bitmaps Marcin Szycik
2023-06-02 13:19   ` Alexander Lobakin
2023-06-05  9:23   ` Simon Horman
2023-06-05 14:21     ` Marcin Szycik [this message]
2023-06-06 13:17     ` Alexander Lobakin
2023-06-06 15:25       ` Simon Horman
2023-06-01 13:19 ` [Intel-wired-lan] [RFC PATCH iwl-next 3/6] pfcp: add PFCP module Marcin Szycik
2023-06-05  9:26   ` Simon Horman
2023-06-01 13:19 ` [Intel-wired-lan] [RFC PATCH iwl-next 4/6] pfcp: always set pfcp metadata Marcin Szycik
2023-06-05  9:34   ` Simon Horman
2023-06-01 13:19 ` [Intel-wired-lan] [RFC PATCH iwl-next 5/6] ice: refactor ICE_TC_FLWR_FIELD_ENC_OPTS Marcin Szycik
2023-06-05  9:36   ` Simon Horman
2023-06-01 13:19 ` [Intel-wired-lan] [RFC PATCH iwl-next 6/6] ice: Add support for PFCP hardware offload in switchdev Marcin Szycik
2023-06-05  9:38   ` Simon Horman

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=98021ae6-cbe4-d0a6-630e-27ae44383376@linux.intel.com \
    --to=marcin.szycik@linux.intel.com \
    --cc=alexandr.lobakin@intel.com \
    --cc=davem@davemloft.net \
    --cc=idosch@nvidia.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jesse.brandeburg@intel.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=simon.horman@corigine.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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