Hi Ilya, Thanks for your comments.
Yes, it's the hardware switch that doesn't do zero padding. Unfortunately, the switch vendor claims that the padding is added after the FCS of the original packet, and there is no way around it. And if it's a requirement to zero pad, then RFC 1042 should use the word "must". As for the "valid reason in special circumstances", the reason is that generating zero padding would have greatly complicated their switch architecture, resulting in additional power consumption and latency. So OVS has to do it. For the other part, where zero padding is to be added to the DPDK interface, no PMD except a few (Atomic Rules, Broadcom, HiSilicon PMDs) do this in the driver, and we use Intel, so that's the reason for doing it in OVS. Regards, Rohit Kumar ________________________________ From: Ilya Maximets <i.maxim...@ovn.org> Sent: Monday, May 20, 2024 11:30 PM To: Kumar, Rohit <roku...@idirect.net>; d...@openvswitch.org <d...@openvswitch.org> Cc: i.maxim...@ovn.org <i.maxim...@ovn.org> Subject: Re: [ovs-dev] [PATCH] netdev: Padding runt packet on VXLAN and DPDK ports. ***WARNING! THIS EMAIL ORIGINATES FROM OUTSIDE ST ENGINEERING IDIRECT.*** On 5/18/24 00:55, Kumar, Rohit via dev wrote: > The basic idea behind this patch is to pad the runt packet before vxlan > encapsulation and on a DPDK port. > > topology: > IXIA <----> SWITCH <--vxlan--> OVS <--dpdk--> HOST > > The host sends a runt packet (54 bytes) with a size less than 64 bytes > to the OVS. The OVS receives this runt packet and sends it further down > the VXLAN tunnel (original packet 54 + 50 VXLAN = 104 B total packet size) > to a physical switch. At the switch, after decapsulation, the original > packet size is 54B and it then sends the packet on to the ixia. However, > the switch adds 2B of padding with random content (not zero as RFC 1042 > mentions) and due to this random byte padding, ixia drops the packet. > > Switch vendors claim to be compliant with both RFC 1042 and RFC 2119 to > fix it in the switch. > > RFC 1042 defines: > “IEEE 802 packets may have a minimum size restriction. When > necessary, the data field should be padded (with octets of zero) > to meet the IEEE 802 minimum frame size requirements. This > padding is not part of the IP datagram and is not included in the > total length field of the IP header.” > > RFC 2119 defines: > "SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course." > > So, a fix is needed in the OVS. The OVS is connected to the switch on a > VXLAN port and to the host on a DPDK port. The padding fix is applied to > both netdev types. I tested the fix in the same setup and below are the > captures after padding on both VXLAN and DPDK ports from OVS UT. > > VXLAN (46B zero pad): > 0000 aa 55 aa 66 00 00 aa 55 aa 55 00 00 08 00 45 00 .U.f...U.U....E. > 0010 00 60 00 00 40 00 40 11 26 81 0a 00 00 02 0a 00 .`..@.@.&....... > 0020 00 0b 9b 77 12 b5 00 4c 00 00 08 00 00 00 00 00 ...w...L........ > 0030 7b 00 50 54 00 00 00 0a 50 54 00 00 00 09 12 34 {.PT....PT.....4 > 0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .............. > > DPDK (16B zero pad): > 0000 ff ff ff ff ff ff 5e fb 90 96 7d b7 08 06 00 01 ......^...}..... > 0010 08 00 06 04 00 01 5e fb 90 96 7d b7 0a 01 01 01 ......^...}..... > 0020 00 00 00 00 00 00 0a 01 01 02 00 00 00 00 00 00 ................ > 0030 00 00 00 00 00 00 00 00 00 00 00 00 ............ > > Signed-off-by: Rohit Kumar <roku...@idirect.net> Hi, Rohit. Thanks for the patch! Though I don't think OVS should add padding to packets. RFC 1042 is talking about transmission to ethernet networks. In your example above OVS sends 104 byte long packet to the ethernet link, so no padding is needed. If the 'SWITCH' in your setup sends incorectly padded packet after decapsulation, that sounds like an issue of that switch. Is this patch a workaround for a hardware switch issue? Also, we even had a request in the past to strip all the existing padding before encapsulation, because older Linux kernel versions had issues processing padded inner packets after decapsulation. Adding the padding will also introduce a difference in behavior between Linux kenrel datapath and the userspace datapath, since Linux kernel doesn't pad packet before encapsulation. Having a difference between datapath implementations is not good. For the part where we add padding before sending to a DPDK interface, this also doesn't seem right. Normally it's a job of a driver to properly pad packets before transmitting them. OVS doesn't know what the requirements for the particular network it is connected to or even if it is an ethernet or some other type of the interface. So, it can't make a decision on padding, only driver can do that. Best regards, Ilya Maximets. This electronic message and any files transmitted with it contains information from ST Engineering iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev