All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Samuelsson <ulf.samuelsson@ericsson.com>
To: David Miller <davem@redhat.com>, <Yanjun.Zhu@windriver.com>
Cc: <brian.haley@hp.com>, <alexandre.dietsch@windriver.com>,
	<clinton.slabbert@windriver.com>, <kuznet@ms2.inr.ac.ru>,
	<jmorris@namei.org>, <kaber@trash.net>, <netdev@vger.kernel.org>
Subject: Re: [PATCH V2 0/1] neighbour: Support broadcast ARP in neighbor PROPE state
Date: Mon, 16 Mar 2015 13:39:47 +0100	[thread overview]
Message-ID: <5506CF13.5070501@ericsson.com> (raw)
In-Reply-To: <20150312.152247.1607789216159086520.davem@redhat.com>

On 03/12/2015 08:22 PM, David Miller wrote:
> Like Yoshifuji and others I agree that:
>
> 1) You can get working behavior by adjusting existing sysctls.
>
> 2) IPV4 ARP and IPV6 NDISC are not different in this regard.
>
> I'm really tired of all of these ARP hacks being submitted recently,
> and I want people to think more deeply about what they are proposing
> first.
Which sysctls are you referring to?

As I can see it, there are three sysctls that control this.

ucast_solicit.
mcast_solicit
app_solicit.

If you think any other sysctl is useful here, which one?

 From Documentation/networking/ip-sysctl.txt.
+++++++++++++
app_solicit - INTEGER
     The maximum number of probes to send to the user space ARP daemon
     via netlink before dropping back to multicast probes (see
     mcast_solicit).  Defaults to 0.
----------------------------
so that ain't it.
If you disagree, what should the Documentation look like?

=============================================
 From net/core/neighbour.c(timer_handler):

     if ((neigh->nud_state & (NUD_INCOMPLETE | NUD_PROBE)) &&
         atomic_read(&neigh->probes) >= neigh_max_probes(neigh)) {
         neigh->nud_state = NUD_FAILED;
         notify = 1;
         neigh_invalidate(neigh);
         goto out;
     }

 From net/core/neighbour.c(neigh_max_probes):
static __inline__ int neigh_max_probes(struct neighbour *n)
{
     struct neigh_parms *p = n->parms;
     int max_probes = NEIGH_VAR(p, UCAST_PROBES) + NEIGH_VAR(p, APP_PROBES);
     if (!(n->nud_state & NUD_PROBE))
         max_probes += NEIGH_VAR(p, MCAST_PROBES);
     return max_probes;
}
=============================================


If we simplify this when we are in NUD_PROBE state we see:

=============================================
     if (atomic_read(&neigh->probes) >= NEIGH_VAR(p, UCAST_PROBES) + 
NEIGH_VAR(p, APP_PROBES)) {
         neigh->nud_state = NUD_FAILED;
         notify = 1;
         neigh_invalidate(neigh);
         goto out;
     }
=============================================

Since APP_PROBES is 0, and according to documentation has nothing to do 
with Broadcast:

=============================================
     if (atomic_read(&neigh->probes) >= NEIGH_VAR(p, UCAST_PROBES)) {
         neigh->nud_state = NUD_FAILED;
         notify = 1;
         neigh_invalidate(neigh);
         goto out;
     }
=============================================

so we will send out "ucast_solicit" unikcast probes, and then we will 
enter FAILED state.
mcast_solicit is ignored when in NUD_PROBE state.

"mcast_solicit" is only used when in NUD_INCOMPLETE state, and 
broadcasts will never
be sent out by the stack for an entry, once it is in NUD_REACHABLE for 
the first time.

I would be happy, if you can show me that I have misunderstood something.

Best Regards,
Ulf Samuelsson

  reply	other threads:[~2015-03-16 12:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-12  6:58 [PATCH V2 0/1] neighbour: Support broadcast ARP in neighbor PROPE state Zhu Yanjun
2015-03-12  6:58 ` [PATCH V2 1/1] " Zhu Yanjun
2015-03-12 10:05   ` YOSHIFUJI Hideaki/吉藤英明
2015-03-12  7:10 ` [PATCH V2 0/1] " yzhu1
2015-03-12  8:42   ` YOSHIFUJI Hideaki
2015-03-12  8:59     ` Ulf samuelsson
2015-03-12  9:28       ` YOSHIFUJI Hideaki/吉藤英明
2015-03-12  9:45         ` Ulf samuelsson
2015-03-12 10:16           ` YOSHIFUJI Hideaki
2015-03-18  8:51     ` Ulf Samuelsson
2015-03-18 10:34       ` YOSHIFUJI Hideaki/吉藤英明
2015-03-18 12:15         ` Ulf Samuelsson
2015-03-18 13:22           ` YOSHIFUJI Hideaki/吉藤英明
2015-03-18 15:12             ` Ulf Samuelsson
2015-03-19  2:42             ` yzhu1
2015-03-19  2:14           ` yzhu1
2015-03-19  2:24       ` yzhu1
2015-03-12 19:22 ` David Miller
2015-03-16 12:39   ` Ulf Samuelsson [this message]
2015-03-19  5:52     ` yzhu1

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5506CF13.5070501@ericsson.com \
    --to=ulf.samuelsson@ericsson.com \
    --cc=Yanjun.Zhu@windriver.com \
    --cc=alexandre.dietsch@windriver.com \
    --cc=brian.haley@hp.com \
    --cc=clinton.slabbert@windriver.com \
    --cc=davem@redhat.com \
    --cc=jmorris@namei.org \
    --cc=kaber@trash.net \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.