On 8/8/24 12:49, Jun Wang wrote:
> We encountered a scenario where, if the received packet contains
> padding bytes, and we then add Geneve tunnel encapsulation without
> carrying the padding bytes, it results in checksum errors when sending
> out.We need to remove the L2 pad immediately after receiving the
> packet, rather than carrying it through the encapsulation.
>
> For example, this type of packet format:
> 0000 06 6c 6a 71 e1 d3 6c e2 d3 8b ea 24 81 00 03 e9
> 0010 08 00 45 00 00 28 9d e5 40 00 3b 06 6e 64 0a 6f
> 0020 05 14 0a fe 19 06 01 bb 22 ae 59 c0 8c 61 8e 26
> 0030 14 e3 50 10 00 7f ce 3a 00 00 00 00 9e 38 cf 64
>
> Fixes: 084c8087292c ("userspace: Support VXLAN and GENEVE TSO.")
> Reported-by: Jun Wang <[email protected]>
> Signed-off-by: Jun Wang <[email protected]>
> ---
> v2: Remove the L2 pad immediately after receiving the packet.
Hi, thanks for v2. But I don't think we should do that for reasons listed here:
https://mail.openvswitch.org/pipermail/ovs-dev/2024-August/416257.html
One more reason may be performance as we'll be parsing the same packet
one more time in order to check for padding, which can be expensive.
We should remove padding during encapsulation instead.
Also, we still need a test for this issue.
> ---
> lib/dp-packet.h | 69
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> lib/netdev-dpdk.c | 1 +
> 2 files changed, 70 insertions(+)
>
> diff --git a/lib/dp-packet.h b/lib/dp-packet.h
> index a75b1c5..c3a2f43 100644
> --- a/lib/dp-packet.h
> +++ b/lib/dp-packet.h
> @@ -726,6 +726,50 @@ dp_packet_set_tso_segsz(struct dp_packet *p, uint16_t s)
> {
> p->mbuf.tso_segsz = s;
> }
> +
> +static inline uint16_t
> +dp_packet_get_total_length(struct dp_packet *p)
> +{
> + struct rte_ether_hdr *eth_hdr;
> + struct rte_vlan_hdr *vlan_hdr;
> + struct rte_ipv4_hdr *ipv4_hdr;
> + struct rte_ipv6_hdr *ipv6_hdr;
And we should not use DPDK-specific structures and functions is there are
generic alternatives.
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
