All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yuwei Wang <wangyuweihx@gmail.com>
To: Paolo Abeni <pabeni@redhat.com>
Cc: davem@davemloft.net, "Jakub Kicinski" <kuba@kernel.org>,
	"Eric Dumazet" <edumazet@google.com>,
	daniel@iogearbox.net, roopa@nvidia.com, dsahern@kernel.org,
	秦迪 <qindi@staff.weibo.com>,
	netdev@vger.kernel.org, "yuwei wang" <wangyuweihx@hotmail.com>
Subject: Re: [PATCH net-next v2] net, neigh: introduce interval_probe_time for periodic probe
Date: Tue, 24 May 2022 22:33:49 +0800	[thread overview]
Message-ID: <CANmJ_FOSfJY7VUQrxb+hX42XjiuF+WZGcbQEiSDRQiRZRBHT9g@mail.gmail.com> (raw)
In-Reply-To: <cf3188eba7e529e4f112f6a752158f38e22f4851.camel@redhat.com>

On Tue, 24 May 2022 at 18:41, Paolo Abeni <pabeni@redhat.com> wrote:
>
> On Tue, 2022-05-24 at 17:38 +0800, Yuwei Wang wrote:
> > On Tue, 24 May 2022 at 16:38, Paolo Abeni <pabeni@redhat.com> wrote:
> > >
> > > On Sun, 2022-05-22 at 03:17 +0000, Yuwei Wang wrote:
> > >
> > > > diff --git a/include/net/netevent.h b/include/net/netevent.h
> > > > index 4107016c3bb4..121df77d653e 100644
> > > > --- a/include/net/netevent.h
> > > > +++ b/include/net/netevent.h
> > > > @@ -26,6 +26,7 @@ enum netevent_notif_type {
> > > >       NETEVENT_NEIGH_UPDATE = 1, /* arg is struct neighbour ptr */
> > > >       NETEVENT_REDIRECT,         /* arg is struct netevent_redirect ptr */
> > > >       NETEVENT_DELAY_PROBE_TIME_UPDATE, /* arg is struct neigh_parms ptr */
> > > > +     NETEVENT_INTERVAL_PROBE_TIME_UPDATE, /* arg is struct neigh_parms ptr */
> > >
> > > Are you sure we need to notify the drivers about this parameter change?
> > > The host will periodically resolve the neighbours, and that should work
> > > regardless of the NIC offload. I think we don't need additional
> > > notifications.
> > >
> >
> > `mlxsw_sp_router_netevent_event` in
> > drivers/net/ethernet/mellanox/mlx5/core/en/rep/neigh.c and
> > `mlx5e_rep_netevent_event` in
> > drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c still
> > use `NETEVENT_DELAY_PROBE_TIME_UPDATE` to receive the update event of
> > `DELAY_PROBE_TIME` as the probe interval.
> >
> > I think we are supposed to replace `NETEVENT_DELAY_PROBE_TIME_UPDATE` with
> > `NETEVENT_INTERVAL_PROBE_TIME_UPDATE` after this patch is merged.
>
> AFAICS the event notification is to let neigh_timer_handler() cope
> properly with NIC offloading the data plane.
>
> In such scenario packets (forwarded by the NIC) don't reach the host,
> and neigh->confirmed can be untouched for a long time fooling
> neigh_timer_handler() into a timeout.
>
> The event notification allows the NIC to perform the correct actions to
> avoid such timeout.
>
> In case of MANAGED neighbour, the host is periodically sending probe
> request, and both req/replies should not be offloaded. AFAICS no action
> is expected from the NIC to cope with INTERVAL_PROBE_TIME changes.

I think `INTERVAL_PROBE_TIME` is not only for MANAGED neighbour,
if the driver needs periodically poll the device for neighbours activity,
we also should use  `INTERVAL_PROBE_TIME` rather than `DELAY_PROBE_TIME` as
the polling interval.

but as
Link: https://lore.kernel.org/netdev/20211011121238.25542-5-daniel@iogearbox.net/

> mlxsw which has similar driver-internal infrastructure
> c723c735fa6b ("mlxsw: spectrum_router: Periodically update the kernel's neigh table").
> In future, the latter could possibly reuse the NTF_MANAGED neighbors as well.

It seems that the behavior probe periodically by the driver will be
deprecated and replaced by setting the MANAGED flag.
or we can keep using `DELAY_PROBE_TIME` before it is replaced?

Look forward to your reply.

Yuwei Wang

  reply	other threads:[~2022-05-24 14:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-22  3:17 [PATCH net-next v2] net, neigh: introduce interval_probe_time for periodic probe Yuwei Wang
2022-05-24  8:38 ` Paolo Abeni
2022-05-24  9:38   ` Yuwei Wang
2022-05-24 10:41     ` Paolo Abeni
2022-05-24 14:33       ` Yuwei Wang [this message]
2022-05-24 15:32       ` Daniel Borkmann
2022-05-24 18:07         ` Jakub Kicinski
2022-05-24 19:13           ` Yuwei Wang
2022-05-24 20:53             ` Daniel Borkmann
2022-06-08 15:02             ` Daniel Borkmann

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=CANmJ_FOSfJY7VUQrxb+hX42XjiuF+WZGcbQEiSDRQiRZRBHT9g@mail.gmail.com \
    --to=wangyuweihx@gmail.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=qindi@staff.weibo.com \
    --cc=roopa@nvidia.com \
    --cc=wangyuweihx@hotmail.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.