Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Reply-To: nicolas.dichtel@6wind.com
Subject: Re: [PATCH net-next v6] net: openvswitch: IPv6: Add IPv6 extension
 header support
To:     Cpp Code <cpp.code.lv@gmail.com>, Jakub Kicinski <kuba@kernel.org>
Cc:     netdev@vger.kernel.org, pshelar@ovn.org,
        "David S. Miller" <davem@davemloft.net>,
        ovs dev <dev@openvswitch.org>, linux-kernel@vger.kernel.org
References: <20210928194727.1635106-1-cpp.code.lv@gmail.com>
 <20210928174853.06fe8e66@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
 <d1e5b178-47f5-9791-73e9-0c1f805b0fca@6wind.com>
 <20210929061909.59c94eff@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
 <CAASuNyVe8z1R6xyCfSAxZbcrL3dej1n8TXXkqS-e8QvA6eWd+w@mail.gmail.com>
From:   Nicolas Dichtel <nicolas.dichtel@6wind.com>
Organization: 6WIND
Message-ID: <b091ef39-dc29-8362-4d31-0a9cc498e8ea@6wind.com>
Date:   Fri, 1 Oct 2021 09:21:29 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <CAASuNyVe8z1R6xyCfSAxZbcrL3dej1n8TXXkqS-e8QvA6eWd+w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

Le 30/09/2021 à 18:11, Cpp Code a écrit :
> On Wed, Sep 29, 2021 at 6:19 AM Jakub Kicinski <kuba@kernel.org> wrote:
>>
>> On Wed, 29 Sep 2021 08:19:05 +0200 Nicolas Dichtel wrote:
>>>> /* Insert a kernel only KEY_ATTR */
>>>> #define OVS_KEY_ATTR_TUNNEL_INFO    __OVS_KEY_ATTR_MAX
>>>> #undef OVS_KEY_ATTR_MAX
>>>> #define OVS_KEY_ATTR_MAX            __OVS_KEY_ATTR_MAX
>>> Following the other thread [1], this will break if a new app runs over an old
>>> kernel.
>>
>> Good point.
>>
>>> Why not simply expose this attribute to userspace and throw an error if a
>>> userspace app uses it?
>>
>> Does it matter if it's exposed or not? Either way the parsing policy
>> for attrs coming from user space should have a reject for the value.
>> (I say that not having looked at the code, so maybe I shouldn't...)
> 
> To remove some confusion, there are some architectural nuances if we
> want to extend code without large refactor.
> The ovs_key_attr is defined only in kernel side. Userspace side is
> generated from this file. As well the code can be built without kernel
> modules.
> The code inside OVS repository and net-next is not identical, but I
> try to keep some consistency.
I didn't get why OVS_KEY_ATTR_TUNNEL_INFO cannot be exposed to userspace.

> 
> JFYI This is the file responsible for generating userspace part:
> https://github.com/openvswitch/ovs/blob/master/build-aux/extract-odp-netlink-h
> This is the how corresponding file for ovs_key_attr looks inside OVS:
> https://github.com/openvswitch/ovs/blob/master/datapath/linux/compat/include/linux/openvswitch.h
> one can see there are more values than in net-next version.
There are still some '#ifdef __KERNEL__'. The standard 'make headers_install'
filters them. Why not using this standard mechanism?

In this file, there are two attributes (OVS_KEY_ATTR_PACKET_TYPE and
OVS_KEY_ATTR_ND_EXTENSIONS) that doesn't exist in the kernel.
This will also breaks if an old app runs over a new kernel. I don't see how it
is possible to keep the compat between {old|new} {kernel|app}.


Regards,
Nicolas