[openib-general] [PATCH Round 4 2/3] Core network changes to support network event notification.
Steve Wise
swise at opengridcomputing.com
Wed Jul 26 09:15:43 PDT 2006
On Wed, 2006-07-26 at 13:39 +1000, Herbert Xu wrote:
> On Tue, Jul 25, 2006 at 10:05:40AM -0500, Steve Wise wrote:
> >
> > But they really are seeing a delete followed by an add. That's what the
> > kernel is doing.
>
> Actually that's the other thing I don't really like. The user-space
> monitor may perceive that a route was actually deleted and replaced
> by a new one even though this isn't what's happening at all.
>
> In fact the problem here is that you're sending route notifications
> when it's really the dst_entry that's changing. User-space as it
> stands only get notifications about fib changes which is quite different
> from changes to the transient dst_entry objects which only exist in the
> route cache.
>
> Is anyone actually going to use the user-space interface of this? If not
> perhaps we should wait until someone really needs it before adding the
> netlink part of the patch.
>
> We can change the kernel interface at will so if we make a mistake with
> netevent it can be easily corrected. For user-space though the rules
> are totally different. I'd really hate to be stuck with an interface
> which turns out to not be the one that people actually want to have.
>
The user interface is not needed for the rdma users. They are all in
kernel. I added this at the request of reviewers of this patch. I have
no problem at all defering the rtnetlink integration until someone
really needs it.
> > The rdma driver needs to update all established rdma connections that
> > are using the next-hop information of the existing route and make them
> > use the next-hop information of the new route. In addition, the rdma
> > driver might have a reference to the old dst entry. So it can release
> > that ref and add a ref to the new dst entry.
>
> Do you really need the old route for the user-space part of your patch?
>
Not if we remove the user-space parts. :-)
> > I have to admit I'm a little fuzzy on the routing stuff. The main
> > netevents I've utilized in the the rdma driver I'm writing is the
> > neighbour update event and the redirect event. Route add/del was added
> > for completeness of "routing" netevents.
>
> So you mean you aren't going to use the route notifications? In that case
> we should probably just drop them and add them when someone actually needs
> it. At that point they can tell us what semantics they want from it :)
>
This is fine by me too! The key events needed for rdma are:
neighbour update events
rtredirect events
pmtu change events
> > Can you expand further or point me to code where the IP stack "flushes
> > its tables" when routes are changed?
>
> Grep for rt_cache_flush in net/ipv4/fib_hash.c.
>
thanks.
Dave, what do you think about removing the user-space stuff for the
first round of integration? IE: Just add netevents and kernel hooks to
generate them.
Steve.
More information about the general
mailing list