netdev - Re: [PATCH net-next 3/5] selftests: drv-net: rss_ctx: test queue changes vs user RSS config

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: <668c4c2cad160_19d5c1294e8@willemb.c.googlers.com.notmuch>
Date: Mon, 08 Jul 2024 16:29:32 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Jakub Kicinski <kuba@...nel.org>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: davem@...emloft.net, 
 netdev@...r.kernel.org, 
 edumazet@...gle.com, 
 pabeni@...hat.com, 
 petrm@...dia.com, 
 przemyslaw.kitszel@...el.com, 
 ecree.xilinx@...il.com
Subject: Re: [PATCH net-next 3/5] selftests: drv-net: rss_ctx: test queue
 changes vs user RSS config

Jakub Kicinski wrote:
> On Mon, 08 Jul 2024 12:56:01 -0400 Willem de Bruijn wrote:
> > > There may be background noise traffic on the main context.
> > > If we are running iperf to the main context the noise will just add up
> > > to the iperf traffic and all other queues should be completely idle.
> > > If we're testing additional context we'll get only iperf traffic on
> > > the target context, and all non-iperf noise stays on main context
> > > (hence noise rather than empty)  
> > 
> > That makes sense. Should the following be inverted then?
> > 
> > +    if main_ctx:
> > +        other_key = 'empty'
> > +        defer(ethtool, f"-X {cfg.ifname} default")
> > +    else:
> > +        other_key = 'noise'
> 
> No, unless I'm confused. if we're testing the main context the other
> queues will be empty. Else we're testing other (additional) contexts
> and queues outside those contexts will contain noise (the queues in 
> the main context, specifically).

Nope, I'm the one who was confused, of course :)

I for some reason assumed that the contexts had exclusive queue sets.
Rather than these being absolute queue indexes and overlapping with
main_ctx.

In which case, understood. Sorry for the noise.