Re: [PATCH 0/2][RFC] Network Event Notifier Mechanism

[Steve Wise <swise@opengridcomputing.com>]

On Thu, 2006-06-22 at 15:43 -0400, jamal wrote:
> On Thu, 2006-22-06 at 10:27 -0500, Steve Wise wrote:
> 
> > 
> > The in-kernel Infiniband subsystem needs to know when certain events
> > happen.  For example, if the mac address of a neighbour changes.  Any
> > rdma devices that are using said neighbour need to be notified of the
> > change.  You are asking that I extend the netlink facility (if
> > necessary) to provide this functionality.  
> > 
> 
> No - what these 2 gents are saying was these events and infrastructure
> already exist. If there are some events that dont and you need to extend
> what already exists. Your patch was a serious reinvention of the wheel
> (and in the case of the neighbor code looking very wrong).

ok.

> As an example, search for NETDEV_CHANGEADDR,NETDEV_CHANGEMTU etc.
> Actually you are probably making this too complicated. 

NETDEV_CHANGEADDR uses a notifier block, and the network subsystem calls
call_netdevice_notifiers() when it sets an addr.  And any kernel module
can register for these events.  That's the model I used to create the
netevent_notifier mechanism in the patch I posted.

I could add the new events to this netdevice notifier, but these aren't
really net device events.  Their network events.  

> Listen to events
> in user space and tell infiniband from user space.
> 

I can indeed extend the rtnetlink stuff to add the events in question
(neighbour mac addr change, route redirect, etc). In fact, there is
similar functionality under the CONFIG_ARPD option to support a user
space arp daemon.  Its not quite the same, and it doesn't cover redirect
and routing events, just neighbour events.

But in the case of the RDMA subsystem, the consumer of these events is
in the kernel.  Why is it better to propagate events all the way up to
user space, then send the event back down into the Infiniband kernel
subsystem?  That seems very inefficient.  

Steve.