Or Gerlitz wrote:
Isaac Huang wrote:
My understanding, which I'd be happy to find false, was that RDMA
cmid couldn't be created and bound to a bonding device. If true,
you're wrong, basically, the bonding device is being seen by the rdma
cm as a clone of its active slave, e.g see slide 8 of my talk @
www.openfabrics.org/archives/spring2007sonoma/Tuesday%20May%201/Gerlitz%20bonding-sonoma-april-26.ppt
When I dug into code, I found when creating bonding device,
alloc_netdev(...ether_setup) will always set net_device::type to
ARPHRD_ETHER, that means if binding cmid on bonding device,
rdma_copy_addr() will always set rdma_dev_addr::dev_type to
RDMA_NODE_RNIC, seems not correct to me... am I wrong?
Rdma_resolve_addr over a cmid bound to the slave also failed with
RDMA_CM_EVENT_ADDR_ERROR status -ETIMEDOUT
But tcpdump output on 'ib2' did show the ARP request and response:
... arp who-has 10.1.1.132 tell 10.1.13.49 hardware #32
... arp reply 10.1.1.132 is-at
80:00:00:49:fe:80:00:00:00:00:00:10:00:03:ba:00:01:00:fb:8a The
response seemed to have been dropped by ARP for some reason
Yes, I believe that these arp replies are being dropped, most likely
in the netif_receive_skb --> skb_bond_should_drop flow, or if you are
running with pretty old kernel as of the slave having the IFF_NOARP
bit set in its flags mask. This explains why arp resolution on the
slave fails.
Or.
We actually are using 2.6.18.128.1.6.el5, which is not old. I agree that
skb_bond_should_drop is the very likely place dropping reply, customer's
bonding is set to active-backup mode, so I think incoming traffic on
inactive slave should be dropped, otherwise same packet could be
delivered for multiple times... So I think using the inactive slave as
standalone interface is not good idea.
Thanks
Liang
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit
http://openib.org/mailman/listinfo/openib-general
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
