>
> On 4/23/2014 8:46 AM, Bart Van Assche wrote:
> > On 04/23/14 14:30, Hal Rosenstock wrote:
> >> On 4/22/2014 2:41 PM, Hefty, Sean wrote:
> >>>> +static u8 cma_get_ib_subnet_timeout(struct rdma_cm_id *id) {
> >>>> + struct ib_port_attr attr;
> >>>> + int ret;
> >>>> +
> >>>> + ret = ib_query_port(id->device, id->port_num, &attr);
> >>>> + return ret == 0 ? attr.subnet_timeout : 18; }
> >>>
> >>> Can we query the port once (or only on a change) and cache the result,
> rather than querying it for every request?
> >>
> >> To be IBA spec compliant, SubnetTimeout could change so some new
> >> local event would need to be added and handled to avoid the requerying.
> >>
> >> In practice, however, that's not very likely AFAIK.
> >
> > Thanks Sean and Hal for the feedback.
> >
> > Regarding SubnetTimeout changes: the code in
> > drivers/infiniband/core/cache.c already queues a work request after
> > each port state change. Inside that work request e.g. the P_Key cache
> > is updated. Would it be acceptable to modify ib_cache_update() such
> > that it also queries the port attributes and caches these ? Cached
> > port attributes could e.g. be stored in struct ib_port. However, doing
> > so would probably require to protect the port_list member in struct
> > ib_device against concurrent modifications of that list by the sysfs code.
>
> Unfortunately, it's possible that the subnet timeout could be modified
> without any of the local events that currently trigger cache update occurring.
The Spec lists SubnetTimeout change as an unaffiliated Asynchronous event in
section 11.6.3.3.
I think adding this event would be the correct course of action when supported.
For HCA's which do not support "port change" events (which I don't think there
are any) I guess a cache could be used.
Does this cache in core/cache.c respond to current events like P_Key table
change?
Ira
>
> -- Hal
>
> > Bart.
> >
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the
> body of a message to [email protected] More majordomo info at
> http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
