From: Steve Wise <[EMAIL PROTECTED]>
Date: Tue, 27 Jun 2006 15:33:19 -0500
> From my experimentation with netlink, RTM_NEWROUTE and RTM_DELROUTE
> messages do not get sent up for redirect events. I have, in fact, added
> this with the new patch I'll send out soon. So either way I need to
> chang
On Tue, 2006-06-27 at 13:21 -0700, David Miller wrote:
> From: Steve Wise <[EMAIL PROTECTED]>
> Date: Tue, 27 Jun 2006 15:19:08 -0500
>
> > For an RDMA NIC, all this logic is in HW, which is why we need the event
> > notification; to tell the HW to change its next hop information.
>
> Back to the
[EMAIL PROTECTED] wrote:
> From: Steve Wise <[EMAIL PROTECTED]>
> Date: Tue, 27 Jun 2006 10:02:19 -0500
>
>> For the RDMA kernel subsystem, however, we still need a specific
>> event. We need both the old and new dst_entry struct ptrs to figure
>> out which active connections were using the old ds
From: Steve Wise <[EMAIL PROTECTED]>
Date: Tue, 27 Jun 2006 10:02:19 -0500
> For the RDMA kernel subsystem, however, we still need a specific event.
> We need both the old and new dst_entry struct ptrs to figure out which
> active connections were using the old dst_entry and should be updated to
>
On Tue, 2006-06-27 at 13:14 -0700, David Miller wrote:
> This change isn't truly atomic from a kernel standpoint either.
>
> The new dst won't be selected by the socket until later,
> when the socket tries to send something, notices the old dst
> is obsolete, and looks up a new one.
>
> Your code
From: Steve Wise <[EMAIL PROTECTED]>
Date: Tue, 27 Jun 2006 15:19:08 -0500
> For an RDMA NIC, all this logic is in HW, which is why we need the event
> notification; to tell the HW to change its next hop information.
Back to the route change notification, I still think you can
get what you need b
On Tue, 2006-06-27 at 03:09 -0700, David Miller wrote:
> From: Steve Wise <[EMAIL PROTECTED]>
> Date: Mon, 26 Jun 2006 15:36:38 -0500
>
> > Round 2 Changes:
> >
> > - cleaned up event structures per review feedback.
> > - began integration with netlink (see neighbour changes in patch 2).
> > - ad
From: Steve Wise <[EMAIL PROTECTED]>
Date: Mon, 26 Jun 2006 15:36:38 -0500
> Round 2 Changes:
>
> - cleaned up event structures per review feedback.
> - began integration with netlink (see neighbour changes in patch 2).
> - added IPv6 support.
Yes, ipv6 support is the main think I saw lacking.
E
Round 2 Changes:
- cleaned up event structures per review feedback.
- began integration with netlink (see neighbour changes in patch 2).
- added IPv6 support.
STILL TODO:
- PMTU events/netlink
- Redirect netlink (need to define a new netlink message for this).
Questions:
- this patch is enabl
