On Mon, Jul 1, 2024 at 10:11 AM junwan...@cestc.cn <junwan...@cestc.cn> wrote: > >I don't think we need to carry this padding over a tunnel. > >I did not test but I wonder if adjusting ip_tot_size is better. > > > >Something like: > > > >@@ -158,7 +158,8 @@ netdev_tnl_push_ip_header(struct dp_packet > >*packet, const void *header, > > struct ovs_16aligned_ip6_hdr *ip6; > > > > eth = dp_packet_push_uninit(packet, size); > >- *ip_tot_size = dp_packet_size(packet) - sizeof (struct eth_header); > >+ *ip_tot_size = dp_packet_size(packet) - dp_packet_l2_pad_size(packet) > >+ - sizeof (struct eth_header); > > > > memcpy(eth, header, size); > > /* The encapsulated packet has type Ethernet. Adjust dp_packet. */ > > > > > Thank you very much for your modification. However, when I verified this > modification, > I found that while sending Geneve-encapsulated packets on the output, the > software > calculation of the inner TCP checksum is still incorrect. I think your > modification approach > might be targeting the checksum of the outer packet. However, if l2_pad_size > is incorrect > and the padding bytes are non-zero, it will cause the inner L4 checksum to be > incorrect.
Let's forget about my (broken) suggestion. On the principle, touching data makes OVS non transparent, which may break something out there. So I think your proposal makes sense. A unit test would be great with it. -- David Marchand _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
