Thanks Jiayu, will add comments to explain it in v5.
At 2020-09-17 10:06:37, "Hu, Jiayu" wrote:
OK, I agree to ignore processing outer IP ID. But I think the comment need to
change, as
it is not accurate. VxLAN/UDP GRO doesn’t process outer IP ID is because it is
meaningles
OK, I agree to ignore processing outer IP ID. But I think the comment need to
change, as
it is not accurate. VxLAN/UDP GRO doesn't process outer IP ID is because it is
meaningless
for reassembly in the ovs case you mentioned, rather than it's out-of-order.
You can
give the ovs example in the com
On Wed, 16 Sep 2020 11:05:38 +0800 (CST)
yang_y_yi wrote:
> No, next_proto_id of inner IP header can clearly identify it is a UDP packet
> even if it is a no-udp-header ip fragment.
Yes GRO will know its UDP, but it will have no port information (in this
packet).
GRO can only safely combine p
No, next_proto_id of inner IP header can clearly identify it is a UDP packet
even if it is a no-udp-header ip fragment.
At 2020-09-16 10:54:24, "Jiayu Hu" wrote:
>On Mon, Sep 14, 2020 at 05:14:59PM +0800, yang_y_yi wrote:
>>
>> Jiayu, VM to VM case for big UDP packet (say ud
On Mon, Sep 14, 2020 at 05:14:59PM +0800, yang_y_yi wrote:
>
> Jiayu, VM to VM case for big UDP packet (say udp parload size is 8192K, but
> mtu
> 1500). VM will segment it as UDP framgments, but when ovs dpdk uses VxLan to
> encapsulate them, it doesn't know they are same flow, OVS DPDK has no k
Jiayu, VM to VM case for big UDP packet (say udp parload size is 8192K, but mtu
1500). VM will segment it as UDP framgments, but when ovs dpdk uses VxLan to
encapsulate them, it doesn't know they are same flow, OVS DPDK has no knowldge
about them, just encapsulate them as if they are not rela
Out IP ID is not used to check if they belong to the same flow,
but check if they are neighbors. If two vxlan/udp fragments are
neighbors, their outer IP ID and outer frag_oft should be incremental.
I still cannot understand why ignore outer IP ID when DF is 0.
Can you give more explanation?
From:
For outer_ip_id, there is same ip_id disorder issue existing as UDP GRO, so we
can't use ip_id +/-1 to check if they are same flow, here is my incrmental
change for it with more comments.
@@ -189,7 +188,12 @@
is_same_vxlan_udp4_flow(struct vxlan_udp4_flow_key k1,
struct vxla
Thanks Jiayu, will change them per your comments. For doument part, is such
change ok?
diff --git a/doc/guides/prog_guide/generic_receive_offload_lib.rst
b/doc/guides/prog
index 5b3fb91..98a5d29 100644
--- a/doc/guides/prog_guide/generic_receive_offload_lib.rst
+++ b/doc/guides/prog_guide
Replies are inline.
BTW, you need to update the programmer guide
doc/guides/prog_guide/generic_receive_offload_lib.rst and
release note doc/guides/rel_notes/release_20_11.rst.
Thanks,
Jiayu
On Mon, Sep 14, 2020 at 10:13:44AM +0800, yang_y_yi wrote:
> Jiayu, thank you so much, please check my rep
From: Yi Yang
VXLAN UDP GRO can help improve VM-to-VM UDP performance
when VM is enabled UFO or GSO, GRO must be supported if
GSO or UFO is enabled, otherwise, performance gain will
be hurt.
With this enabled in DPDK, OVS DPDK can leverage it to
improve VM-to-VM UDP performance, this will make s
11 matches
Mail list logo
