[EMAIL PROTECTED] wrote: > From: Steve Wise <[EMAIL PROTECTED]> > Date: Tue, 27 Jun 2006 10:02:19 -0500 > >> For the RDMA kernel subsystem, however, we still need a specific >> event. We need both the old and new dst_entry struct ptrs to figure >> out which active connections were using the old dst_entry and should >> be updated to use the new dst_entry. > > This change isn't truly atomic from a kernel standpoint either. > > The new dst won't be selected by the socket until later, when > the socket tries to send something, notices the old dst is > obsolete, and looks up a new one. > > Your code could do the same thing.
The request to "send something" is posted directly form user mode to a mapped memory ring that is reaped by the hardware. Having the hardware fault, report that fault, and wait for the host to update it with the new mapping is somewhat clumbsy. It also won't work at all for existing hardware. The best you could do is to have the driver invalidate the old entry, then *presume* that the hardware will want the replacement and look that up, and then forward that answer to the hardware. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
