Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates
 12.22.5.236 as permitted sender) receiver=protection.outlook.com;
 client-ip=12.22.5.236; helo=mail.nvidia.com;
References: <20220309222033.3018976-1-i.maximets@ovn.org>
 <f7ty21hir5v.fsf@redhat.com>
 <44eeb550-3310-d579-91cc-ec18b59966d2@nvidia.com>
 <1a185332-3693-2750-fef2-f6938bbc8500@ovn.org>
User-agent: mu4e 1.6.6; emacs 27.2
From:   Vlad Buslov <vladbu@nvidia.com>
To:     Ilya Maximets <i.maximets@ovn.org>
CC:     Roi Dayan <roid@nvidia.com>, Aaron Conole <aconole@redhat.com>,
        "Jakub Kicinski" <kuba@kernel.org>,
        "David S. Miller" <davem@davemloft.net>,
        "Pravin B Shelar" <pshelar@ovn.org>,
        Toms Atteka <cpp.code.lv@gmail.com>, <netdev@vger.kernel.org>,
        <dev@openvswitch.org>, <linux-kernel@vger.kernel.org>,
        Johannes Berg <johannes@sipsolutions.net>,
        Maor Dickman <maord@nvidia.com>
Subject: Re: [PATCH net-next v2] net: openvswitch: fix uAPI incompatibility
 with existing user space
Date:   Thu, 7 Apr 2022 11:02:03 +0300
In-Reply-To: <1a185332-3693-2750-fef2-f6938bbc8500@ovn.org>
Message-ID: <87k0c171ml.fsf@nvidia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Apr 2022 09:13:08.7383
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 20568d00-d41e-46b0-490b-08da1876d538
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a;Ip=[12.22.5.236];Helo=[mail.nvidia.com]
X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT035.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4440
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE,
	URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon 14 Mar 2022 at 20:40, Ilya Maximets <i.maximets@ovn.org> wrote:
> On 3/14/22 19:33, Roi Dayan wrote:
>>=20
>>=20
>> On 2022-03-10 8:44 PM, Aaron Conole wrote:
>>> Ilya Maximets <i.maximets@ovn.org> writes:
>>>
>>>> Few years ago OVS user space made a strange choice in the commit [1]
>>>> to define types only valid for the user space inside the copy of a
>>>> kernel uAPI header.=C2=A0 '#ifndef __KERNEL__' and another attribute w=
as
>>>> added later.
>>>>
>>>> This leads to the inevitable clash between user space and kernel types
>>>> when the kernel uAPI is extended.=C2=A0 The issue was unveiled with the
>>>> addition of a new type for IPv6 extension header in kernel uAPI.
>>>>
>>>> When kernel provides the OVS_KEY_ATTR_IPV6_EXTHDRS attribute to the
>>>> older user space application, application tries to parse it as
>>>> OVS_KEY_ATTR_PACKET_TYPE and discards the whole netlink message as
>>>> malformed.=C2=A0 Since OVS_KEY_ATTR_IPV6_EXTHDRS is supplied along with
>>>> every IPv6 packet that goes to the user space, IPv6 support is fully
>>>> broken.
>>>>
>>>> Fixing that by bringing these user space attributes to the kernel
>>>> uAPI to avoid the clash.=C2=A0 Strictly speaking this is not the probl=
em
>>>> of the kernel uAPI, but changing it is the only way to avoid breakage
>>>> of the older user space applications at this point.
>>>>
>>>> These 2 types are explicitly rejected now since they should not be
>>>> passed to the kernel.=C2=A0 Additionally, OVS_KEY_ATTR_TUNNEL_INFO mov=
ed
>>>> out from the '#ifdef __KERNEL__' as there is no good reason to hide
>>>> it from the userspace.=C2=A0 And it's also explicitly rejected now, be=
cause
>>>> it's for in-kernel use only.
>>>>
>>>> Comments with warnings were added to avoid the problem coming back.
>>>>
>>>> (1 << type) converted to (1ULL << type) to avoid integer overflow on
>>>> OVS_KEY_ATTR_IPV6_EXTHDRS, since it equals 32 now.
>>>>
>>>> =C2=A0 [1] beb75a40fdc2 ("userspace: Switching of L3 packets in L2 pip=
eline")
>>>>
>>>> Fixes: 28a3f0601727 ("net: openvswitch: IPv6: Add IPv6 extension heade=
r support")
>>>> Link: https://lore.kernel.org/netdev/3adf00c7-fe65-3ef4-b6d7-6d8a0cad8=
a5f@nvidia.com
>>>> Link: https://github.com/openvswitch/ovs/commit/beb75a40fdc295bfd6521b=
0068b4cd12f6de507c
>>>> Reported-by: Roi Dayan <roid@nvidia.com>
>>>> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
>>>> ---
>>>
>>> Acked-by: Aaron Conole <aconole@redhat.com>
>>>
>>=20
>>=20
>>=20
>> I got to check traffic with the fix and I do get some traffic
>> but something is broken. I didn't investigate much but the quick
>> test shows me rules are not offloaded and dumping ovs rules gives
>> error like this
>>=20
>> recirc_id(0),in_port(enp8s0f0_1),ct_state(-trk),eth(),eth_type(0x86dd),i=
pv6(frag=3Dno)(bad
>> key length 2, expected -1)(00 00/(bad mask length 2, expected -1)(00 00),
>> packets:2453, bytes:211594, used:0.004s, flags:S., actions:ct,recirc(0x2)
>
> Such a dump is expected, because kernel parses fields that current
> userspace doesn't understand, and at the same time OVS by design is
> using kernel provided key/mask while installing datapath rules, IIRC.
> It should be possible to make these dumps a bit more friendly though.
>
> For the offloading not working, see my comment in the v2 patch email
> I sent (top email of this thread).  In short, it's a problem in user
> space and it can not be fixed from the kernel side, unless we revert
> IPv6 extension header support and never add any new types, which is
> unreasonable.  I didn't test any actual offloading, but I had a
> successful run of 'make check-offloads' with my quick'n'dirty fix from
> the top email.

Hi Ilya,

I can confirm that with latest OvS master IPv6 rules offload still fails
without your pastebin code applied.

>
> Since we're here:
>
> Toms, do you plan to submit user space patches for this feature?

I see there is a patch from you that is supposed to fix compatibility
issues caused by this change in OvS d96d14b14733 ("openvswitch.h: Align
uAPI definition with the kernel."), but it doesn't fix offload for me
without pastebin patch. Do you plan to merge that code into OvS or you
require some help from our side?

Regards,
Vlad

[...]