Re: sense remote hardware address change by rdma-cm applications

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Tue, Jul 20, 2010 at 01:12:17PM -0500, Steve Wise wrote:

> The cxgb* drivers actually reference the neigh and dst structs until the  
> offload connection is gone.  Also if the the offloaded connection has  
> problems transmitting (due to a L2 address change, for example), then  
> the driver will initiate ND again by calling neigh_event_send().  See  
> t4_l2t_send_event() in l2t.c which is called by the iwarp driver in  
> peer_abort() from iwch_cm.c when the HW tells us its retransmitting too  
> much.

That strikes me as mildly scary.. The cxgb can't possibly get the
right dst (ie, the same dst that the RDMA CM got) in all the corner
cases? Ie how can setting oif to 0 in iwch_cm.c:find_route be right??

So, looks like there is a larger cleanup here, if the RDMACM holds the
dst and has functions to freshen it/track it then the iwarp driver
should rely on the RDMACM to manage the dst..

In other words, moving the dst handling from iwch_cm into RDMACM would
also mostly satisfy why Or is trying to do.

Does that make sense to you Steve?

How does the cxgb3 driver know when to update the HW if the dst/nd
entries change?

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html