All of lore.kernel.org
 help / color / mirror / Atom feed
From: jamal <hadi@cyberus.ca>
To: Steve Wise <swise@opengridcomputing.com>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [PATCH 0/2][RFC] Network Event Notifier Mechanism
Date: Thu, 22 Jun 2006 16:36:37 -0400	[thread overview]
Message-ID: <1151008597.5392.118.camel@jzny2> (raw)
In-Reply-To: <1151007524.3040.48.camel@stevo-desktop>

On Thu, 2006-22-06 at 15:18 -0500, Steve Wise wrote:
> On Thu, 2006-06-22 at 15:43 -0400, jamal wrote:

> > 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.
> 

it also gets emmited as a netlink event.

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

Different blocks for sure - the point is the infrastructure which
constitutes using notifiers exists. And it is joined at the hip with
netlink.


> 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.
> 

CONFIG_ARPD will give you all neighbor events you need. 
=> rt_redirect doesnt exist neither do route cache
creation/updates/deletions. FIB changes exist etc

> 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.  

Your mileage may vary. If you do it in user space you dont have to wait
for the next kernel release in case of a bug. Additionally, it allows
for more feature richness that would tend to bloat the kernel/infiniband
otherwise. 

Out of curiosity - what does RDMA NIC have that would need these events?
a route table or L2 table etc? Can you elucidate a little?

cheers,
jamal


  reply	other threads:[~2006-06-22 20:36 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-21 18:45 [PATCH 0/2][RFC] Network Event Notifier Mechanism Steve Wise
2006-06-21 18:45 ` [PATCH 1/2] " Steve Wise
2006-06-21 18:45 ` [PATCH 2/2] Core network changes to support network event notification Steve Wise
2006-06-21 19:08 ` [PATCH 0/2][RFC] Network Event Notifier Mechanism YOSHIFUJI Hideaki / 吉藤英明
2006-06-22  8:57 ` David Miller
2006-06-22 13:53   ` Steve Wise
2006-06-22 15:27     ` Steve Wise
2006-06-22 19:43       ` jamal
2006-06-22 20:18         ` Steve Wise
2006-06-22 20:36           ` jamal [this message]
2006-06-22 20:58             ` Steve Wise
2006-06-22 22:14               ` jamal
2006-06-23 13:11                 ` Steve Wise
2006-06-22 20:40         ` Steve Wise
2006-06-22 20:56           ` jamal
2006-06-23 13:17             ` Steve Wise
  -- strict thread matches above, loose matches on Subject: below --
2006-06-21 19:48 Steve Wise
2006-06-21 20:40 ` David Miller
2006-06-22 22:11 Caitlin Bestler
2006-06-22 22:21 ` jamal
2006-06-22 22:58 ` David Miller
2006-06-23  0:56   ` jamal
2006-06-23 13:24     ` Steve Wise
2006-06-23 19:57       ` David Miller
2006-06-23 20:12         ` Steve Wise
2006-06-24 14:30       ` jamal
2006-06-26 14:34         ` Steve Wise
2006-06-27 12:44           ` jamal
2006-06-22 22:39 Caitlin Bestler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1151008597.5392.118.camel@jzny2 \
    --to=hadi@cyberus.ca \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=swise@opengridcomputing.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.