All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lawrence Lee" <lfqlee314@gmail.com>
To: "Ido Schimmel" <idosch@nvidia.com>
Cc: "David Ahern" <dsahern@kernel.org>,
	"David S . Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Simon Horman" <horms@kernel.org>,
	"Arun Ajith S" <aajith@arista.com>,
	"Roopa Prabhu" <roopa@nvidia.com>,
	"Jaehee Park" <jhpark1013@gmail.com>, <netdev@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [RFC net-next] ipv6: update NUD_FAILED neighbors from NA messages
Date: Fri, 28 Aug 2026 16:54:00 +0000	[thread overview]
Message-ID: <DL0QFI20UBL6.3BM3CZWLDS1K3@gmail.com> (raw)
In-Reply-To: <20260827090516.GA2014023@shredder>

On Thu Aug 27, 2026 at 9:05 AM UTC, Ido Schimmel wrote:
> On Tue, Aug 25, 2026 at 06:07:44PM +0000, Lawrence Lee wrote:
> > Sorry I should have been more specific before. Maybe a better way to 
> > phrase it is that this would be analogous to IPv4 in the sense that it 
> > allows NUD_FAILED neighbors to change states upon receipt of a NA, but 
> > by using NUD_STALE it remains consistent with RFC9131 Section 6.1.1.
>
> I think that your setup is quite unique and I don't necessarily agree
> with the statements regarding the CPU load, but it doesn't change my
> conclusion: IMO it makes sense to transition from FAILED to STALE when
> receiving NAs (most likely unsolicited given FAILED state).
>
> Mention in the commit message that trying to resolve FAILED neighbours
> by periodically probing them (e.g., using NTF_EXT_MANAGED) adds extra
> work compared to having the kernel stop ignoring the information that
> it's getting via NAs. Also mention that the approach taken here is more
> conservative than IPv4, which by default transitions FAILED neighbours
> to STALE upon receiving GARPs.

I will be sure to mention these points in the message. Is it appropriate 
to credit you with a 'Suggested-By' tag in the commit messages as well?  
I'm not sure what the proper attribution convention is here for commit 
message content.

> Note that you also need to update the RFC 9131 comment in
> ndisc_recv_na() and the description of accept_untracked_na in
> Documentation/networking/ip-sysctl.rst. In addition, please add a test
> case in tools/testing/selftests/net/ndisc_unsolicited_na_test.sh
>
> Before submitting, please read:
> https://docs.kernel.org/next/process/maintainer-netdev.html
>
> Run the CI checks locally:
> https://github.com/linux-netdev/nipa#running-locally
>
> And LLM review:
> https://github.com/sashiko-dev/sashiko#1-local-review-recommended
>
> Thanks

Will do, thanks for the suggestions. I will submit a patch once the tree 
re-opens.

  reply	other threads:[~2026-08-28 16:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-13 23:33 [RFC net-next] ipv6: update NUD_FAILED neighbors from NA messages Lawrence Lee
2026-08-25 11:52 ` Ido Schimmel
2026-08-25 18:07   ` Lawrence Lee
2026-08-27  9:05     ` Ido Schimmel
2026-08-28 16:54       ` Lawrence Lee [this message]
2026-08-30 11:27         ` Ido Schimmel

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=DL0QFI20UBL6.3BM3CZWLDS1K3@gmail.com \
    --to=lfqlee314@gmail.com \
    --cc=aajith@arista.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=jhpark1013@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=roopa@nvidia.com \
    /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.