netdev - Re: bonding xmit

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 15 Nov 2011 01:20:36 -0500
From:	Simon Chen <simonchennj@...il.com>
To:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: bonding xmit_policy

Thanks, my bad.

It is pretty strange that when I use 802.3ad mode, all my packets
(from different TCP flows) egress the same NIC even though I choose
xmit_policy to be layer3+4. That's why I wasn't quite sure whether the
policy is indeed in place.

When I switch to balance-xor mode, the packets are roughly evenly
distributed across two NICs.

-Simon

On Sun, Nov 13, 2011 at 3:26 PM, Nicolas de Pesloüan
<nicolas.2p.debian@...il.com> wrote:
> Le 13/11/2011 03:55, Simon Chen a écrit :
>>
>> Hi folks,
>>
>> It looks like that there are three entries in xmit_policy (hashing for
>> deciding egress phy int) for bonded interfaces:
>>
>> const struct bond_parm_tbl xmit_hashtype_tbl[] = {
>> {       "layer2",               BOND_XMIT_POLICY_LAYER2},
>> {       "layer3+4",             BOND_XMIT_POLICY_LAYER34},
>> {       "layer2+3",             BOND_XMIT_POLICY_LAYER23},
>> {       NULL,                   -1},
>> };
>>
>>
>> We can set the xmit_policy either at module initiation, or later via
>> /sys. However, this xmit_policy isn't really read anywhere. Are
>> different policies really implemented?
>
> The table is used in two different locations:
>
> In drivers/net/bonding/bond_main.c:
>
>        xmit_hashtype = bond_parse_parm(xmit_hash_policy, xmit_hashtype_tbl);
>        [...]
>        params->xmit_policy = xmit_hashtype;
>
> In drivers/net/bonding/bond_sysfs.c:
>
>        new_value = bond_parse_parm(buf, xmit_hashtype_tbl);
>        [...]
>        bonds->params.xmit_policy = new_value;
>
> Then, in drivers/net/bonding/bond_main.c, the value in
> bonds->params.xmit_policy is used to setup a callback into
> bond->xmit_hash_policy.
>
>        static void bond_set_xmit_hash_policy(struct bonding *bond)
>        {
>                switch (bond->params.xmit_policy) {
>                case BOND_XMIT_POLICY_LAYER23:
>                        bond->xmit_hash_policy = bond_xmit_hash_policy_l23;
>                        break;
>                case BOND_XMIT_POLICY_LAYER34:
>                        bond->xmit_hash_policy = bond_xmit_hash_policy_l34;
>                        break;
>                case BOND_XMIT_POLICY_LAYER2:
>                default:
>                        bond->xmit_hash_policy = bond_xmit_hash_policy_l2;
>                        break;
>                }
>        }
>
> Then, in drivers/net/bonding/bond_3ad.c and in
> drivers/net/bonding/bond_main.c, the callback is used to select a slave for
> xmit, for the two modes where xmit_hash_policy have a meaning:
>
>        slave_agg_no = bond->xmit_hash_policy(skb, slaves_in_agg);
>
>        slave_no = bond->xmit_hash_policy(skb, bond->slave_cnt);
>
>
> So, yes, those policies are really implemented.
>
>        Nicolas.
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html