Re: [PATCH] libibverbs: Expose the get neighbor timeout for dmac resolution

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/8/19 8:02 AM, Majd Dibbiny wrote:
> 
>> On May 8, 2019, at 5:31 PM, Jason Gunthorpe <jgg@xxxxxxxxxxxx> wrote:
>>
>> On Tue, May 07, 2019 at 05:55:25PM +0000, Adit Ranadive wrote:
>>>>> // Configuration defaults
>>>>>
>>>>> #define IBACM_SERVER_MODE_UNIX 0
>>>>> diff --git a/libibverbs/verbs.c b/libibverbs/verbs.c
>>>>> index 1766b9f52d31..2cab86184e32 100644
>>>>> +++ b/libibverbs/verbs.c
>>>>> @@ -967,7 +967,6 @@ static inline int create_peer_from_gid(int family, void *raw_gid,
>>>>>    return 0;
>>>>> }
>>>>>
>>>>> -#define NEIGH_GET_DEFAULT_TIMEOUT_MS 3000
>>>>> int ibv_resolve_eth_l2_from_gid(struct ibv_context *context,
>>>>>                struct ibv_ah_attr *attr,
>>>>>                uint8_t eth_mac[ETHERNET_LL_SIZE],
>>>>
>>>> Really compile time configurations are not so useful, what is the use
>>>> case here? 
>>>>
>>>
>>> In the general sense I agree with you. Pre-built RPMs may not have this
>>> set to anything other than the default value. 
>>> However, in our internal testing we've seen timeouts when trying to
>>> resolve the DMAC when creating an AH.
> You can do this using uverbs instead of netlink by changing the create_ah provider’s implementation.. and AFAIR it’s more scalable than netlink..

Thanks Majid! We will mostly go down that route later but in the fallback
case we will still need to the L2 lookup function...

>>> Instead, of simply increasing
>>> the #define value here I thought it would be mildly helpful to expose 
>>> this out.
>>>
>>> If this is not going to be useful I can drop it but I thought it would 
>>> atleast make rdma-core a bit more configurable..
>>
>> Stuff like this should not be configured.. if you are hitting timeout
>> it sounds like a bug of some sort to me.
>>
>> Jason





[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux