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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CADjXwjimPFM4Ut0Zv0cZh0DviwW=CrAb=XV5zLeX+4d__OayDg@mail.gmail.com>
Date:   Thu, 5 Aug 2021 13:21:18 -0700
From:   Coco Li <lixiaoyan@...gle.com>
To:     Paolo Abeni <pabeni@...hat.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
        Willem de Bruijn <willemb@...gle.com>,
        Tanner Love <tannerlove@...gle.com>
Subject: Re: [PATCH net-next 1/2] selftests/net: GRO coalesce test

On Thu, Aug 5, 2021 at 4:16 AM Paolo Abeni <pabeni@...hat.com> wrote:
>
> 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.

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?