netdev - Re: [PATCH net 2/3] selftests: bonding: re-format bond option tests

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:   Wed, 5 Apr 2023 20:23:01 -0400
From:   Jonathan Toppins <jtoppins@...hat.com>
To:     Hangbin Liu <liuhangbin@...il.com>
Cc:     netdev@...r.kernel.org, Jay Vosburgh <j.vosburgh@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>, Liang Li <liali@...hat.com>
Subject: Re: [PATCH net 2/3] selftests: bonding: re-format bond option tests

On 4/5/23 05:57, Hangbin Liu wrote:
> On Tue, Apr 04, 2023 at 12:34:03PM -0400, Jonathan Toppins wrote:
>>>>> I like this idea, we might want to separate network topology from library
>>>>> code however. That way a given test case can just include a predefined
>>>>
>>>> Would you like to help explain more clear? Separate network topology to where?
>>>
>>>
>>> Hi Jon, would you please help explain this part?
>>
>> Thanks for the ping. It looks like several test cases build largely the same
>> virtual network topology and then execute the test case. I was attempting to
>> point out that it might be better to provide a standard network topology and
>> then each test case utilizes this standard topology instead of each test
>> case rolling its own. Also, with my comment about separating out the
>> topology from library code I was accounting for the ability to support
>> multiple topologies, fe:
>>
>>   bond_lib.sh
>>   bond_topo_gateway.sh
>>   bond_topo_2.sh
>>
>> Then a given test case only includes/sources `bond_topo_gateway.sh` which
>> creates the virtual network.
> 
> Thank Jon, this is much clear to me now. I'm not good at naming.
> For topology with 2 down link devices, 1 client, I plan to name it
> bond_topo_2d1c.sh. So 3 down links devices, 2 clients will be
> bond_topo_3d2c.sh. If there is no switch between server and client, it could
> be bond_topo_2d1c_ns.sh.
> 
> I'm not sure if the name is weird to you. Any comments?
> 

Hi Hangbin, I do not have a particular preference for the naming. What 
you have proposed seems good to me.

-Jon