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

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

From: Coco Li <hidden>
Date: 2021-08-05 20:21:31

On Thu, Aug 5, 2021 at 4:16 AM Paolo Abeni [off-list ref] wrote:
Hello,

On Thu, 2021-08-05 at 07:36 +0000, Coco Li wrote:
quoted
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.
Thanks for the suggestion! To make sure I understand you correctly,
would this be another script that creates the veth pair separate from
the gro.sh wrapper?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help