[ofa-general] can an ib-bonding slave work independently?

[Liang Zhen]

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
> general at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>
> To unsubscribe, please visit 
> http://openib.org/mailman/listinfo/openib-general