[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20140919210040.E09BA481010@fruggeri-Arora18.sjc.aristanetworks.com>
Date: Fri, 19 Sep 2014 14:00:40 -0700
From: fruggeri@...stanetworks.com (Francesco Ruggeri)
To: netdev@...r.kernel.org
Cc: fruggeri@...sta.com, davem@...emloft.net,
herbert@...dor.apana.org.au
Subject: cannot ARP macvlan on top of bonding device
[Resending with correct date]
Ping in the following test fails:
# Create veth pair v1 v2
ip link add v1 type veth peer name v2
# Stack macvlan on top of bonding device on top of v1
ip link set v1 up
ip link add bond1 type bond
ip link set bond1 up
ifenslave bond1 v1
ip link add link bond1 name mac1 type macvlan mode bridge
ip link set mac1 up
ifconfig mac1 1.2.3.1/24
# Move v2 to namespace dummy2 and ping v1
ip netns add dummy2
ip link set v2 netns dummy2
ip netns exec dummy2 bash
ip link set lo up
ip link set v2 up
ifconfig v2 1.2.3.2/24
ping 1.2.3.1 -c 5
# Clean up
exit
ip netns del dummy2
ip link del bond
It passes on older releases.
The problem is that txqueuelen in bond1 is 0, and ARP requests are dropped in macvlan_broadcast_enqueue at:
if (skb_queue_len(&port->bc_queue) < skb->dev->tx_queue_len) {
__skb_queue_tail(&port->bc_queue, nskb);
err = 0;
}
where
port->dev = skb->dev = "bond1"
skb_queue_len(&port->bc_queue) = skb->dev->tx_queue_len = 0
macvlan_broadcast_enqueue was introduced in 412ca1550 (macvlan: Move broadcasts into a work queue).
Why are we using tx_queue_len to limit an rx queue?
Thanks,
Francesco Ruggeri
--
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
Powered by blists - more mailing lists