Re: [ovs-dev] [PATCH net-next v8] net: openvswitch: IPv6: Add IPv6 extension header support

From: Eelco Chaudron
Date: Wed Mar 02 2022 - 08:59:32 EST




On 2 Mar 2022, at 11:50, Roi Dayan wrote:

> On 2022-03-02 12:03 PM, Roi Dayan wrote:
>>
>>
>> On 2022-02-25 12:40 PM, patchwork-bot+netdevbpf@xxxxxxxxxx wrote:
>>> Hello:
>>>
>>> This patch was applied to netdev/net-next.git (master)
>>> by David S. Miller <davem@xxxxxxxxxxxxx>:
>>>
>>> On Wed, 23 Feb 2022 16:54:09 -0800 you wrote:
>>>> This change adds a new OpenFlow field OFPXMT_OFB_IPV6_EXTHDR and
>>>> packets can be filtered using ipv6_ext flag.
>>>>
>>>> Signed-off-by: Toms Atteka <cpp.code.lv@xxxxxxxxx>
>>>> Acked-by: Pravin B Shelar <pshelar@xxxxxxx>
>>>> ---
>>>>   include/uapi/linux/openvswitch.h |   6 ++
>>>>   net/openvswitch/flow.c           | 140 +++++++++++++++++++++++++++++++
>>>>   net/openvswitch/flow.h           |  14 ++++
>>>>   net/openvswitch/flow_netlink.c   |  26 +++++-
>>>>   4 files changed, 184 insertions(+), 2 deletions(-)
>>>
>>> Here is the summary with links:
>>>    - [net-next,v8] net: openvswitch: IPv6: Add IPv6 extension header support
>>>      https://git.kernel.org/netdev/net-next/c/28a3f0601727
>>>
>>> You are awesome, thank you!
>>
>> Hi,
>>
>> After the merge of this patch I fail to do ipv6 traffic in ovs.
>> Am I missing something?
>>
>> ovs-vswitchd.log has this msg
>>
>> 2022-03-02T09:52:26.604Z|00013|odp_util(handler1)|WARN|attribute packet_type has length 2 but should have length 4
>>
>> Thanks,
>> Roi
>
>
> I think there is a missing userspace fix. didnt verify yet.
> but in ovs userspace odp-netlink.h created from datapath/linux/compat/include/linux/openvswitch.h
> and that file is not synced the change here.
> So the new enum OVS_KEY_ATTR_IPV6_EXTHDRS is missing and also struct
> ovs_key_ipv6_exthdrs which is needed in lib/udp-util.c
> in struct ovs_flow_key_attr_lens to add expected len for
> OVS_KEY_ATTR_IPV6_EXTHDR.

I guess if this is creating backward compatibility issues, this patch should be reverted/fixed. As a kmod upgrade should not break existing deployments.