<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">

  <title></title>

</head>

<body bgcolor="#ffffff" text="#000000">

Right, there should only be one route lookup call.  And the send_arp

should match what TCP/UDP are doing, I'm pretty sure they don't use

neigh_event_send like ib_addr is, or if they do, they are not using

ip_route_output_key to get the neighbor entry.  I could not find the

code that generates arps for these protocols.  <br>

<br>

addr_resolve_local should do the same as you said, although I didn't

exercise this code when testing, I was testing with a single/stable

remote node's IP.  I'll see if there's a better fix then.<br>

<br>

Thanks for your help.<br>

<br>

Leo Tominna<br>

<br>

On 7/13/2009 1:20 PM, Jason Gunthorpe wrote:

<blockquote cite="mid:20090713202006.GB21867@obsidianresearch.com"

 type="cite">

  <pre wrap="">On Mon, Jul 13, 2009 at 10:14:05AM -0700, <a class="moz-txt-link-abbreviated" href="mailto:leo.tominna@oracle.com">leo.tominna@oracle.com</a> wrote:

  </pre>

  <blockquote type="cite">

    <pre wrap="">Hi Jason,

Thanks for clearing up the use case.  In that case doing ip_dev_find to set oif

would be wrong since it would not work correctly in the case the same IP is

associated with two devices. By just setting s_addr before calling

ip_route_output_key in addr_send_arp, that should take care of it (the initial

patch sent).

>From what I can tell, this just fixes the policy routing case, without

affecting/addressing configurations that are using default routing.  I need to

see why RDS/IB gets stuck in this case.  My guess is that hardware addresses

don't get resolved correctly (as expected), and two sides of an IB connection

trip over a mismatch in what hardware a peer thinks its using.

But that is another issue that can be fixed independently.  I'll add some

prints to see what might be happening.

    </pre>

  </blockquote>

  <pre wrap=""><!---->

So, I think they might be related, at least, the current arrangement

seems straneg to my eyes.

There should be only one route lookup and it should not be in the

send_arp function.

The ip_dev_find (and related) in addr_resolve_local is the main

culprit.. As far as I can see there should be one call to the route

function (ip_route_output_key??) and that result should replace

ip_dev_find and the dst and fl, etc should be passed down to send_arp

and the other places that are calling ip_route_output_key. (This is

the original problem I noted in that old thread)

Multiple lookups like this seem like they should be racy against table

updates.

So you patch makes the arp part use a potentialy different device than

the bind part, which is no good.. (yes?)

Really, the best thing to do here is carefully look at the tcp and udp

call paths and duplicate their function calls into the route

module. It should be the same logic flow.

Jason

  </pre>

</blockquote>

</body>

</html>