netdev - Re: [PATCH net] ip_tunnel: allow to inherit from VLAN encapsulated IP frames

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]

Date:   Thu, 21 Jul 2022 10:25:34 +0200
From:   Matthias May <matthias.may@...termo.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     <netdev@...r.kernel.org>, <davem@...emloft.net>,
        <yoshfuji@...ux-ipv6.org>, <dsahern@...nel.org>,
        <edumazet@...gle.com>, <pabeni@...hat.com>,
        <nicolas.dichtel@...nd.com>, Eyal Birger <eyal.birger@...il.com>
Subject: Re: [PATCH net] ip_tunnel: allow to inherit from VLAN encapsulated IP
 frames

On 7/20/22 18:50, Jakub Kicinski wrote:
> On Wed, 20 Jul 2022 17:24:17 +0200 Matthias May wrote:
>> I finally got around to do the previously mentioned selftest for gretap, vxlan and geneve.
>> See the bash-script below.
>>
>> Many of the vxlan/geneve tests are currently failing, with gretap working on net-next
>> because of the fixes i sent.
>> What is the policy on sending selftests that are failing?
>> Are fixes for the failures required in advance?
>>
>> I'm not sure i can fix them.
>> Geneve seems to ignore the 3 upper bits of the DSCP completely.
>>
>> My other concern is:
>> The whole test is... slow.
>> I tried to figure out what takes so long, and the culprit seem to be tcpdump.
>> It just takes ages to start capturing, more so when it is capturing IPv6.
>> Does anyone know of a better way to capture traffic and analyze it afterwards?
>> I used tcpdump because other tests seem to use it, and i guess this is a tool
>> that most everyone has installed (that works with networks).
> 
> Yeah, tcpdump is not great, there's a bunch of flags that make it a
> little less bad (--immediate-mode?)
> 
> Looking at the last test I wrote I ended up with:
> 
> tcpdump --immediate-mode -p -ni dummy0 -w $TMPF -c 4
> sleep 0.05 # wait for tcpdump to start

Thank you for the hint with the immediate-mode, that already shaved over a minute off.

Before:
real	3m40.056s
user	0m4.103s
sys	0m2.434s

After:
real	2m34.438s
user	0m3.955s
sys	0m2.350s

BR
Matthias

Download attachment "OpenPGP_0xDF76B604533C0DBE.asc" of type "application/pgp-keys" (670 bytes)

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (237 bytes)