[openib-general] re the core network changes to support network event notification

[Steve Wise]

On Tue, 2006-08-08 at 13:54 +0300, Or Gerlitz wrote:
> Steve,
> 
> Tracking in the netdev archive the threads related to the netevents 
> patch, i have noted that you were attempting to add support for two 
> "netlink update events" (RTM_NEIGHUPD RTM_ROUTEUPD) but eventually the 
> patch that was merged by Dave (round 5) did not include these events.
> 
> Did you had any spcial reason to drop them?  is it correct that the
> merged code does implement a framework for adding them later?
> 

I dropped them at the request of the reviewers because they weren't
correct and they aren't needed for kernel netevent subscribers.  I also
dropped ROUTE add/delete events because they weren't correct either.
And I don't think they are needed for RDMA drivers.

The framework is there to add all this later if needed...

> Can you spare few words about the differences from a **kernel** consumer
> point of view between being a direct netevent vs netlink consumer?
> 

netlink is for user space consumers.  netlink is a socket family and
allows creating a socket with one end hooked to various kernel
subsystems and the other end to a user process.  Then the user and
kernel can do IPC and exchange messages.  

rtnetlink is a routing netlink socket that is used to pass routing
events up to user processes (like routing daemons) as well as for these
same daemons to send commands to the kernel to add/del routes.  If
you're a unix guy rtnetlink implements BSD AF_ROUTE sockets.

netlink/rtnetlink was never intended to pass messages between kernel
subsystems, although it could be done by using kernel sockets, but that
is kind of overkill in that the information is marshalled into a
message, and then unmarshalled by the other end.  For user<->kernel
thats fine.  But it is a waste for intra-kernel event notifications.  

Netevents use the linux notifier block mechanism to allow consumers to
register a direct function callback to receive netevents.  For neighbour
update events, the callback is passed the neigh ptr that was updated.
For ICMP redirects, the callback is passed the old and new dst_entry
ptrs.  For PMTU changes, the dst_entry ptr is passed.


> I guess IPoIB code would be able to take advantage of RTM_NEIGHUPD netlink event
> or a netevents based filter to remove the data path memcmp on the neigh HA address.
> 

I haven't looked at the IPoIB code.  What is it doing exactly (I am
somewhat familiar with the IPoIB specification and how it works)?


Steve.