[ofa-general] RE: [RFC] [PATCH 0/3] 2.6.22 or 23 ib: add path record cache

[Sean Hefty]

>Isn't there a way to get notice for this?

The closest trap I'm aware of is GID in/out of service.  See 14.2.5.1 and
14.4.9.  GID in/out of service is related to the existence of a path record
between the SGID and DGID.  If the path record parameters change, I'm not sure
if the GID technically goes out, then back into service or not.  Maybe Hal
knows.

>I haven't thought this through yet. Basically, I just note that
>caching the path until GID goes out of service isn't right -
>since path parameters such as MTU or rate might change
>without GID going out of service.
>
>So what to do?
>
>We could use DR SMPs to do network discovery and at least check
>that paths are valid - it's not too much code (ibnetdiscover is just 800 lines)
>and in a sense, that's actually putting an *SA* (not just cache) in each node.
>Combined with GID IN/OUT notices we could get away from querying path records
>completely.

My guess (and it's only a guess at this point) is that the impact of each node
sending stream of DR SMPs to continually discover the network will be worse than
sending GetTable queries to the SA.

One thought I had was to provide a feedback mechanism back into the cache to
invalidate paths.  For example, the ib_cm could invalidate a path if it times
out trying to establish a connection or notices that path migration has
occurred.  I think implementing either of these is further out.

>At least the reregister/LID set events flush the cache.

The reregister/LID events will also flush the SA cache.

- Sean