(re-send as for some reason gmail rejected the previous attempt and it wasn't delivered to Vladislav)
On 11/13/23 20:25, Ilya Maximets wrote: > On 11/13/23 13:13, Eelco Chaudron wrote: >> >> >> On 13 Nov 2023, at 12:43, Vladislav Odintsov wrote: >> >>>> On 13 Nov 2023, at 14:17, Eelco Chaudron <[email protected]> wrote: >>>> >>>> >>>> >>>> On 8 Nov 2023, at 14:39, Vladislav Odintsov wrote: >>>> >>>>> Hi Ilya, Eelco, >>>>> >>>>> I’ve tried this patch against 3.1 and latest master branch. There are no >>>>> warnings anymore, >>>>> but it seems that in my installation it has broken offload capability. >>>> >>>> Yes, this is expected, this specific flow can not be offloaded with TC and >>>> therefore will be processed by the kernel datapath. >>> >>> But why did it work before the patch? The traffic was offloaded to it was >>> flowing correctly. >> >> It seemed to work, but your rule had an action to set the source port to >> 59507, however, this is not happening with tc. >> >> >> actions:set(tunnel(tun_id=0xff0011,src=10.1.0.109,dst=10.1.1.18,ttl=64,tp_src=59507,tp_dst=6081,geneve({class=0x102,type=0x80,len=4,0x18000b}),flags(df|csum|key))),4 >> >> If you still want to offload this flow, you should not configure the tp_src >> for this action, and it will be offloaded. >> >> Ilya, is this done by OVN? If so, it might need a change there also. > > I don't think there is a direct way to force the tp_src into the action. > OVS is making decision based on the set of flows it has, but I'm not > sure why exactly. > > Vladislav, could you try running ofproto/trace for the packet of interest > on your setup? This may shed some light on why exactly OVS wants this > field to be part of the action. > > But, as Eelco said, as long as this field is part of the action, we > can't allow it to be offloaded, just because TC doesn't support it. > > Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
