Jason Gunthorpe wrote:
On Tue, Jul 20, 2010 at 03:50:05PM -0500, Steve Wise wrote:
I think if RDMACM manages the dst and lets the devices access it then
all the existing netdev infrastructure for poking at a dst should be
available to the device?
Yes. But I'm not sure exactly how the logic I described previous for
cxgb* would be handled in the design being ironed out here.
I'm thinking something like this..
- The RDMA CM gets the dst from its route lookup locks it and stores
it.
- Instead of doing a route lookup cxgb gets the dst from RDMA CM,
locks it and stores it
- RDMA CM traps all notifications/etc and generates callback to cxgb
to say the dst has changed.
- cxgb releases the old dst and grabs the new one, updates the HW,
etc.
Basically the same as what you have now, but all the logic to find
and monitor the dst moves to RDMA CM..
redirects/etc are all handled by netdev/rdma cm and just generate the
same 'dst has changed' call back to cxgb..
Or's user space notification stuff hooks the same callback to generate
a notification to userspace about the new dst.
All the stuff you do now with the dst you can keep doing, you just
remove all the route lookup and netdev hooking to get the dst from
RDMA CM.
Jason
Sounds like this would work nicely.
Steve.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
