Sean:
Sorry for the delay ...
I think what would happen in that case is that the ARP request would get
queued, but never resolved because the ARP reply would never hit the
host (it's eaten by the adapter itself).
So eventually the request would timeout, fail to find a resolved next
hop, and end up delivering an error to the CMA via the callback.
On Fri, 2006-02-10 at 10:02 -0800, Sean Hefty wrote:
> Tom,
>
> Can you tell me if this alternate patch would work? I let the ib_addr module
> queue the callback. No CMA changes are necessary then.
>
> Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
>
> ---
>
> Index: addr.c
> ===================================================================
> --- addr.c (revision 5295)
> +++ addr.c (working copy)
> @@ -36,6 +36,7 @@
>
> #include <linux/inetdevice.h>
> #include <linux/workqueue.h>
> +#include <linux/if_arp.h>
> #include <net/arp.h>
> #include <net/neighbour.h>
> #include <net/route.h>
> @@ -163,6 +164,12 @@ static int addr_resolve_remote(struct so
> if (ret)
> goto out;
>
> + /* If the device does ARP internally, return 'done' */
> + if (rt->idev->dev->flags & IFF_NOARP) {
> + copy_addr(addr, rt->idev->dev, NULL);
> + return 0;
> + }
> +
> neigh = neigh_lookup(&arp_tbl, &rt->rt_gateway, rt->idev->dev);
> if (!neigh) {
> ret = -ENODATA;
>
>
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
