netdev - Re: [PATCH net-next 11/13] selftests: ncdevmem: Remove hard-coded queue numbers

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: <ZvYIZpgBMe0wMouL@mini-arch>
Date: Thu, 26 Sep 2024 18:20:38 -0700
From: Stanislav Fomichev <stfomichev@...il.com>
To: Mina Almasry <almasrymina@...gle.com>
Cc: Stanislav Fomichev <sdf@...ichev.me>, netdev@...r.kernel.org,
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com
Subject: Re: [PATCH net-next 11/13] selftests: ncdevmem: Remove hard-coded
 queue numbers

On 09/26, Mina Almasry wrote:
> On Thu, Sep 12, 2024 at 2:47 PM Stanislav Fomichev <stfomichev@...il.com> wrote:
> >
> > On 09/12, Mina Almasry wrote:
> > > On Thu, Sep 12, 2024 at 10:13 AM Stanislav Fomichev <sdf@...ichev.me> wrote:
> > > >
> > > > Use single last queue of the device and probe it dynamically.
> > > >
> > >
> > > Can we use the last N queues, instead of 1? Or the last half of the queues?
> > >
> > > Test coverage that we can bind multiple queues at once is important, I think.
> >
> > Anything against doing this in the selftest/probe part?
> >
> > if (probe) {
> >         if (start_queue > 1) {
> >                 /* make sure can bind to multiple queues */
> >                 start_queue -= 1;
> >                 num_queues +=1;
> 
> Sorry for the late reply, this particular thread slipped my inbox.

So what's better? Hard-coding start_queue and num_queues to 8?
This is only for the purpose of self testing, not sure we really care.
 
> Overriding user-provided configs here doesn't seem great. It's nice to
> be able to launch ncdevmem requesting 1 queue to be bound or multiple,
> and I had the idea that in the future the tests can be improved to
> verify that multiple concurrent connections on multiple queues can be
> handled correctly, in case we run into any bugs that can only be
> reproduced in this setup.

Currently, having multiple queues doesn't make any sense because there
is only a single receiver. I have some patches to have a thread per
receiver, can post them if you're interested (after we sort out this
series).