Thanks. Look forward to the fix… From: Dave Barach (dbarach) <dbar...@cisco.com> Sent: Tuesday, March 05, 2019 8:25 PM To: Kingwel Xie <kingwel....@ericsson.com>; vpp-dev@lists.fd.io Subject: RE: ip-rewrite bug?
Let’s try to fix the underlying code in vnet_rewrite_one_header, and friends. The code already checks for the magic rewrite length 14. Anyhow, the header-rewrite scheme hasn’t had a serious performance tuning pass in a long time. Since it’s used everywhere, shaving a couple of clock cycles from it would be a Good Thing... D. From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> On Behalf Of Kingwel Xie Sent: Tuesday, March 5, 2019 4:40 AM To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: [vpp-dev] ip-rewrite bug? Hi vpp-dev, I’m looking at the ip-rewrite node, and I think it might be a bug at: vnet_rewrite_one_header (adj0[0], ip0, sizeof (ethernet_header_t)); The adj-> rewrite_header.data_bytes might be 0 when it comes to tunnel interface, f.g., gtpu, ipsec. Thus, at least 8 bytes garbage are written to buffer unexpectedly. I came across to this because I’m doing handoff for tunnel interface, and in this case, 8 bytes memcpy leads to some performance loss, cache trashing… Temporarily I created a patch for more discussion. Please take a look. There should be a better way to fix it… https://gerrit.fd.io/r/18014 Regards, Kingwel
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12437): https://lists.fd.io/g/vpp-dev/message/12437 Mute This Topic: https://lists.fd.io/mt/30224541/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
