[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bd58b5a8-de29-d80c-9440-4809162951db@intel.com>
Date: Fri, 2 Jun 2023 15:19:52 +0200
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: Marcin Szycik <marcin.szycik@...ux.intel.com>
CC: <intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>,
<wojciech.drewek@...el.com>, <michal.swiatkowski@...ux.intel.com>,
<alexandr.lobakin@...el.com>, <davem@...emloft.net>, <kuba@...nel.org>,
<jiri@...nulli.us>, <pabeni@...hat.com>, <jesse.brandeburg@...el.com>,
<simon.horman@...igine.com>, <idosch@...dia.com>
Subject: Re: [RFC PATCH iwl-next 2/6] ip_tunnel: convert __be16 tunnel flags
to bitmaps
From: Marcin Szycik <marcin.szycik@...ux.intel.com>
Date: Thu, 1 Jun 2023 15:19:25 +0200
> From: Alexander Lobakin <alexandr.lobakin@...el.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.
[...]
Little comment on this: yes, I'm planning to extend UAPI to be able to
use more bits, but using Netlink bigint, which I posted last autumn,
then switched to another project, now I'm a little (a ton) busy with
urgent another one... Hopefully I'll send v3 in 2 weeks or so.
PFCP doesn't depend on it anyway, so this can be done separately.
Thanks,
Olek
Powered by blists - more mailing lists