Messages in this thread | | | From | Eelco Chaudron <> | Subject | Re: [ovs-dev] [PATCH net-next v8] net: openvswitch: IPv6: Add IPv6 extension header support | Date | Wed, 02 Mar 2022 14:59:21 +0100 |
| |
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@kernel.org wrote: >>> Hello: >>> >>> This patch was applied to netdev/net-next.git (master) >>> by David S. Miller <davem@davemloft.net>: >>> >>> 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@gmail.com> >>>> Acked-by: Pravin B Shelar <pshelar@ovn.org> >>>> --- >>>> 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.
| |