On Thu, Jul 19, 2012 at 4:18 PM, Or Gerlitz <[email protected]> wrote: > From: Shlomo Pongratz <[email protected]> > > Dave Miller <[email protected]> provided a detailed description of why the > way IPoIB is using neighbours for its own ipoib_neigh struct is buggy: [...]
> This patch aims to solve the race conditions found in the IPoIB driver. > > The patch breaks the connection between the core networking neighbour > structure > and the ipoib_neigh structure. Except for avoiding the race, it allows to in > under a setup where SKBs carrying IP packets that don't have any associated > neighbour are transmitted through IPoIB. > > We add an ipoib_neigh hash table with 1024 buckets. The hash table key is the > destin > hardware address. Thus the ipoib_neigh is fetched from the hash table and not > dereferenced from the stashed location at the neighbour structure. The hash > table uses > both RCU and reference count mechanisms to guarantee that no ipoib_neigh > instance is > ever deleted while in use. > > Fetching the ipoib_neigh structure instance from the hash also makes the > special > code in ipoib_start_xmit that handles remote and local bonding failover > redundant. > > Aged ipoib_neigh instances are deleted by a garbage collection task that runs > every > 30 seconds and deletes every ipoib_neigh instance that was idle for at least > 60 > seconds. The deletion is safe since the ipoib_neigh instances are protected > using RCU and reference count mechanisms. Hi Dave, Roland, Eric So how does this look? in the right direction? anything that need to be fixed? Or. -- 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
