On Mon, 2006-26-06 at 09:34 -0500, Steve Wise wrote:
> On Sat, 2006-06-24 at 10:30 -0400, jamal wrote:
> The route/hh cache insertions might work for the initial dst MAC per
> next-hop IP. But this dst MAC can _change_ for various reasons (even
> though the next-hop IP remains the same). Such a
On Sat, 2006-06-24 at 10:30 -0400, jamal wrote:
> On Fri, 2006-23-06 at 08:24 -0500, Steve Wise wrote:
>
> >
> > > PS:- I do think what they need is to hear route cache generation
> > > as opposed to ARP+FIB updates; but lets wait and see how clever
> > > the patches would look.
> > >
>
> > Ca
On Fri, 2006-23-06 at 08:24 -0500, Steve Wise wrote:
>
> > PS:- I do think what they need is to hear route cache generation
> > as opposed to ARP+FIB updates; but lets wait and see how clever
> > the patches would look.
> >
> Can you expand on your statement above? If hooking route cache
> ge
On Fri, 2006-06-23 at 12:57 -0700, David Miller wrote:
> From: Steve Wise <[EMAIL PROTECTED]>
> Date: Fri, 23 Jun 2006 08:24:43 -0500
>
> > On Thu, 2006-06-22 at 20:56 -0400, jamal wrote:
> > > On Thu, 2006-22-06 at 15:58 -0700, David Miller wrote:
> > >
> > > > Anyways, we can create normal noti
From: Steve Wise <[EMAIL PROTECTED]>
Date: Fri, 23 Jun 2006 08:24:43 -0500
> On Thu, 2006-06-22 at 20:56 -0400, jamal wrote:
> > On Thu, 2006-22-06 at 15:58 -0700, David Miller wrote:
> >
> > > Anyways, we can create normal notifiers for neighbour and route
> > > events just like we have for netw
On Thu, 2006-06-22 at 20:56 -0400, jamal wrote:
> On Thu, 2006-22-06 at 15:58 -0700, David Miller wrote:
>
> > Anyways, we can create normal notifiers for neighbour and route
> > events just like we have for network device stuff.
> >
So did you agree with a new notifier head for these events as i
On Thu, 2006-06-22 at 16:56 -0400, jamal wrote:
> On Thu, 2006-22-06 at 15:40 -0500, Steve Wise wrote:
> > On Thu, 2006-06-22 at 15:43 -0400, jamal wrote:
> > >
> > > No - what these 2 gents are saying was these events and infrastructure
> > > already exist.
> >
> > Notification of the exact eve
> >
> > > 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?
> > >
> >
> > Mainly the L2 table, next hop ip addr, and the path mtu. RDMA NICs
> > implement the entire RDMA stack in HW. How they deal with L2
On Thu, 2006-22-06 at 15:58 -0700, David Miller wrote:
> Anyways, we can create normal notifiers for neighbour and route
> events just like we have for network device stuff.
>
> There should be netlink counterparts for that stuff too, which
> are generated by the notifier calls or similar.
Sounds
From: "Caitlin Bestler" <[EMAIL PROTECTED]>
Date: Thu, 22 Jun 2006 15:11:27 -0700
> I don't have any strong opinion on the best mechanism
> for implementing these subscriptions, but having correct
> consistent networking behaviour depend on a user-mode
> relay strikes me as odd.
Never heard of a
[EMAIL PROTECTED] wrote:
> On Thu, 2006-22-06 at 15:58 -0500, Steve Wise wrote:
>> On Thu, 2006-06-22 at 16:36 -0400, jamal wrote:
>
>> I created a new notifier block in my patch for these network events.
>> I guess I thought I was using the existing infrastructure to provide
>> this notification
On Thu, 2006-22-06 at 15:11 -0700, Caitlin Bestler wrote:
> [EMAIL PROTECTED] wrote:
>
> These subscriptions are an attempt to cede full control
> of these issues back to one place, the kernel, and to
> guarantee that an offload device can never think that
> the route to to X is Y when the kerne
On Thu, 2006-22-06 at 15:58 -0500, Steve Wise wrote:
> On Thu, 2006-06-22 at 16:36 -0400, jamal wrote:
> I created a new notifier block in my patch for these network events. I
> guess I thought I was using the existing infrastructure to provide this
> notification service. (I thought my patch wa
[EMAIL PROTECTED] wrote:
> On Thu, 2006-22-06 at 15:40 -0500, Steve Wise wrote:
>> On Thu, 2006-06-22 at 15:43 -0400, jamal wrote:
>>>
>>> No - what these 2 gents are saying was these events and
>>> infrastructure already exist.
>>
>> Notification of the exact events needed does not exist today.
On Thu, 2006-06-22 at 16:36 -0400, jamal wrote:
> 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.
> >
>
On Thu, 2006-22-06 at 15:40 -0500, Steve Wise wrote:
> On Thu, 2006-06-22 at 15:43 -0400, jamal wrote:
> >
> > No - what these 2 gents are saying was these events and infrastructure
> > already exist.
>
> Notification of the exact events needed does not exist today.
>
Ok, so you cant event
On Thu, 2006-06-22 at 15:43 -0400, jamal wrote:
>
> No - what these 2 gents are saying was these events and infrastructure
> already exist.
Notification of the exact events needed does not exist today.
The key events, again, are:
- the neighbour entry mac address has changed.
- the next ho
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 sub
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 neig
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 t
On Thu, 2006-06-22 at 08:53 -0500, Steve Wise wrote:
> On Thu, 2006-06-22 at 01:57 -0700, David Miller wrote:
> > From: Steve Wise <[EMAIL PROTECTED]>
> > Date: Wed, 21 Jun 2006 13:45:19 -0500
> >
> > > This patch implements a mechanism that allows interested clients to
> > > register for notifica
On Thu, 2006-06-22 at 01:57 -0700, David Miller wrote:
> From: Steve Wise <[EMAIL PROTECTED]>
> Date: Wed, 21 Jun 2006 13:45:19 -0500
>
> > This patch implements a mechanism that allows interested clients to
> > register for notification of certain network events.
>
> We have a generic network ev
From: Steve Wise <[EMAIL PROTECTED]>
Date: Wed, 21 Jun 2006 13:45:19 -0500
> This patch implements a mechanism that allows interested clients to
> register for notification of certain network events.
We have a generic network event notification facility called
netlink, please use it and extend it
In article <[EMAIL PROTECTED]> (at Wed, 21 Jun 2006 13:45:19 -0500), Steve Wise
<[EMAIL PROTECTED]> says:
> This patch implements a mechanism that allows interested clients to
> register for notification of certain network events. The intended use
> is to allow RDMA devices (linux/drivers/infinib
This patch implements a mechanism that allows interested clients to
register for notification of certain network events. The intended use
is to allow RDMA devices (linux/drivers/infiniband) to be notified of
neighbour updates, ICMP redirects, path MTU changes, and route changes.
The reason these
25 matches
Mail list logo
