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
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.
_______________________________________________
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
