sorry, ack name is wrong: Acked-by: Peng He <[email protected]>
Peng He <[email protected]> 于2022年5月9日周一 11:36写道： > the patch looks good to me. and I also tried to merge it on the master, it > works. > > Acked-by: hepeng.0320 <[email protected]> > > > > > > Hemanth Aramadaka <[email protected]> 于2022年5月4日周三 18:00写道： > >> 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]> 于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]> >> *Sent:* 16 March 2022 11:30 >> *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 >> >> >> >> 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]> 于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. >> Re-iterating the same patch request on the latest master code. >> >> Signed-off-by: Hemanth Aramadaka <[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] >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev >> >> >> >> >> -- >> >> hepeng >> >> >> >> >> -- >> >> hepeng >> > > > -- > hepeng > -- hepeng _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
