Thread (6 messages) flat view 6 messages, 3 authors, 2021-08-05

Re: [PATCH net-next 1/2] selftests/net: GRO coalesce test

From: Paolo Abeni <pabeni@redhat.com>
Date: 2021-08-05 11:16:44

Hello,

On Thu, 2021-08-05 at 07:36 +0000, Coco Li wrote:
Implement a GRO testsuite that expects Linux kernel GRO behavior.
All tests pass with the kernel software GRO stack. Run against a device
with hardware GRO to verify that it matches the software stack.

gro.c generates packets and sends them out through a packet socket. The
receiver in gro.c (run separately) receives the packets on a packet
socket, filters them by destination ports using BPF and checks the
packet geometry to see whether GRO was applied.

gro.sh provides a wrapper to run the gro.c in NIC loopback mode.
It is not included in continuous testing because it modifies network
configuration around a physical NIC: gro.sh sets the NIC in loopback
mode, creates macvlan devices on the physical device in separate
namespaces, and sends traffic generated by gro.c between the two
namespaces to observe coalescing behavior.
I like this idea a lot!

Have you considered additionally run the same test of top of a veth
pair, and have such tests always enabled, so we could have some
coverage regardless of specific H/W available?

To do the above you should disable TSO on the veth sender peer and
enable GRO on the other end.

[...]
+  setup_ns
+  # Each test is run 3 times to deflake, because given the receive timing,
+  # not all packets that should coalesce will be considered in the same flow
+  # on every try.
I thought that tuning 'gro_flush_timeout' appropriatelly, you should be
able to control exactly which packets will be aggregated ???

Thanks!

Paolo
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help