Hi Peng,
Could you please review the below request. Thanks, Hemanth. From: Peng He <[email protected]> Sent: 08 April 2022 07:50 To: Hemanth Aramadaka <[email protected]> Cc: Sriharsha Basavapatna via dev <[email protected]>; Ilya Maximets <[email protected]> Subject: Re: [ovs-dev] [PATCH] flow: Consistent VXLAN UDP src ports for fragmented packets got it. thanks! Hemanth Aramadaka <[email protected] <mailto:[email protected]> > 于2022年4月8日周五 00:36写道： Hi, Here we are not fragmenting VXLAN packets in the outer IP header.The packets originating from VM with the larger size than the configured MTU will get fragmented and these inner packets are encapsulated with vxlan header in which we have the different source ports for UDP. Thanks, Hemanth. From: Peng He <[email protected] <mailto:[email protected]> > Sent: 16 March 2022 11:30 To: Hemanth Aramadaka <[email protected] <mailto:[email protected]> > Cc: Sriharsha Basavapatna via dev <[email protected] <mailto:[email protected]> >; Ilya Maximets <[email protected] <mailto:[email protected]> > Subject: Re: [ovs-dev] [PATCH] flow: Consistent VXLAN UDP src ports for fragmented packets Normally, VXLAN packets will be set to DF( don't frag) in the outter IP header. I am trying to understand why fragmentation happens in the first place. Hemanth Aramadaka via dev <[email protected] <mailto:[email protected]> > 于2022年3月15日周二 22:38写道： Issue: The src-port for UDP is based on RSS hash in the packet metadata. In case of packets coming from VM it will be 5-tuple, if available, otherwise just IP addresses.If the VM fragments a large IP packet and sends the fragments to ovs, only the first fragment will contain the L4 header. Therefore, the first fragment and subsequent fragments get different UDP src ports in the outgoing VXLAN header.This can lead to fragment re-ordering in the fabric as packet will take different paths. Fix: Intention of this is to avoid fragment packets taking different paths. For example, due to presence of firewalls, fragment packets will take different paths and will get dropped.To avoid this we ignore the L4 header during hash calculation only in the case of fragmented packets. P.S: There is already a review request raised for the same. https://mail.openvswitch.org/pipermail/ovs-dev/2021-January/379395.html. <https://mail.openvswitch.org/pipermail/ovs-dev/2021-January/379395.html.Re-iterating> Re-iterating the same patch request on the latest master code. Signed-off-by: Hemanth Aramadaka <[email protected] <mailto:[email protected]> > --- lib/flow.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/lib/flow.c b/lib/flow.c index dd523c889..17bd47724 100644 --- a/lib/flow.c +++ b/lib/flow.c @@ -2238,7 +2238,7 @@ miniflow_hash_5tuple(const struct miniflow *flow, uint32_t basis) if (flow) { ovs_be16 dl_type = MINIFLOW_GET_BE16(flow, dl_type); - uint8_t nw_proto; + uint8_t nw_proto,nw_frag; if (dl_type == htons(ETH_TYPE_IPV6)) { struct flowmap map = FLOWMAP_EMPTY_INITIALIZER; @@ -2260,6 +2260,14 @@ miniflow_hash_5tuple(const struct miniflow *flow, uint32_t basis) nw_proto = MINIFLOW_GET_U8(flow, nw_proto); hash = hash_add(hash, nw_proto); + /* Skip l4 header fields if IP packet is fragmented since + * only first fragment will carry l4 header. + */ + nw_frag = MINIFLOW_GET_U8(flow, nw_frag); + if ((nw_frag)) { + goto out; + } + if (nw_proto != IPPROTO_TCP && nw_proto != IPPROTO_UDP && nw_proto != IPPROTO_SCTP && nw_proto != IPPROTO_ICMP && nw_proto != IPPROTO_ICMPV6) { -- 2.25.1 _______________________________________________ dev mailing list [email protected] <mailto:[email protected]> https://mail.openvswitch.org/mailman/listinfo/ovs-dev -- hepeng -- hepeng _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
