On Wed, May 30, 2018, Pravin Shelar <[email protected]> wrote: > I am not sure why are you seeing frag_list for large UDP packet, STT > would linearize such UDP packet. > https://github.com/openvswitch/ovs/blob/06db81ccfe6d4c779de2ca73033abd7020db419b/datapath/linux/compat/stt.c#L299 > Can you check why are you seeing frag_list after STT decapsulation?
We are. The skb dump in my original post was from well past decapsulation. > Is SKIP_ZERO_COPY defined for the STT build? Yes. It seems because we have CONFIG_SLUB enabled for our kernel: https://github.com/openvswitch/ovs/blob/06db81ccfe6d4c779de2ca73033abd7020db419b/datapath/linux/compat/stt.c#L52 > May be the assumption in try_to_segment() is not true for skb > generated by certain NICs. > ref: > https://github.com/openvswitch/ovs/blob/06db81ccfe6d4c779de2ca73033abd7020db419b/datapath/linux/compat/stt.c#L566 > In that case we need to fix STT. In our case since it's a large GSO UDP packet, then ->next is NULL. This would cause coalesce_skb() to be skipped: https://github.com/openvswitch/ovs/blob/branch-2.7/datapath/linux/compat/stt.c#L1456 Then try_to_segment is skipped because SKIP_ZERO_COPY is defined. While the comment here appears to be true: https://github.com/openvswitch/ovs/blob/branch-2.7/datapath/linux/compat/stt.c#L563 It appears it doesn't take into account NICs may generate a frag_list? I'm not a networking expert, but as far as I can tell, the large skb from this solarflare NIC appears to be valid (uses frag_list). I'm not familiar with the OVS code to understand why the linearize is necessary. It seems like that would impact performance significantly. JE _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
