Mimicking the exact behaviour of Mellanox NICs when performing software GSO in homa_gso_segment:homa_offload.c. For IPv4, Mellanox NICs will assign an incremental ip.id for segments from a GSO segment. For example, if a GSO segment will result in 6 MTU size packets. The ip.id in the 1st packet (segment) will be 0 and the last will be 6. For the next GSO segment, the ip.id will start from 0 again.
However, the current homa_gso_segment only split the segments but does not assign the ip.id(s), leading to different behaviour compared to Mellanox NIC TSO. This patch fixes this problem by adding ip.id to the segs in homa_gso_segment when the IP version is IPv4. To be noticed, IPv6 doesn't contain id field so we don't need to care.
I also provide related .pcap files in homa-gso-segment-ipid.zip. With default max_gso_size and 1500B MTU, for 10000B, we would expect two GSO segments, one with 6 packets and one with 2 packets after segmentation, for 2840 we would expect two MTU size packet from one GSO segment ending up 0-1ip.id(s). node0 sends the packets and installed with HomaModule, node1 receives the packets but no HomaModule installed. For virtio NICs I also uncommented skb_shinfo(skb)->gso_type = 0xd; to make software GSO at least work.
For the Mellanox ones we can see the ip.id(s) result in 0-1-2-3-4-5-0-1 for 10000B and 0-1 for 2840B.
For the virtio with unpatched HomaModule we can see the ip.id(s) result all zero for both.
For the virtio with patched HomaModule we can see the ip.id(s) is same with Mellanox hardware TSO.
Mimicking the exact behaviour of Mellanox NICs when performing software GSO in
homa_gso_segment:homa_offload.c. For IPv4, Mellanox NICs will assign an incrementalip.idfor segments from a GSO segment. For example, if a GSO segment will result in 6 MTU size packets. Theip.idin the 1st packet (segment) will be0and the last will be6. For the next GSO segment, theip.idwill start from0again.However, the current homa_gso_segment only split the segments but does not assign the ip.id(s), leading to different behaviour compared to Mellanox NIC TSO. This patch fixes this problem by adding
ip.idto thesegsinhoma_gso_segmentwhen the IP version is IPv4. To be noticed, IPv6 doesn't containidfield so we don't need to care.I also provide related
.pcapfiles in homa-gso-segment-ipid.zip. With defaultmax_gso_sizeand 1500B MTU, for 10000B, we would expect two GSO segments, one with 6 packets and one with 2 packets after segmentation, for 2840 we would expect two MTU size packet from one GSO segment ending up0-1ip.id(s).node0sends the packets and installed with HomaModule,node1receives the packets but no HomaModule installed. For virtio NICs I also uncommentedskb_shinfo(skb)->gso_type = 0xd;to make software GSO at least work.ip.id(s) result in0-1-2-3-4-5-0-1for 10000B and0-1for 2840B.ip.id(s) result all zero for both.ip.id(s) is same with Mellanox hardware TSO.