All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jack Ma <jack4it@gmail.com>
To: Ido Schimmel <idosch@nvidia.com>, netdev@vger.kernel.org
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>, Shuah Khan <shuah@kernel.org>,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jack Ma <jack4it@gmail.com>
Subject: Re: [PATCH net-next 0/3] net: nexthop: per-nexthop UDP dst port for fdb (VXLAN) nexthops
Date: Fri, 17 Jul 2026 06:07:43 +0000	[thread overview]
Message-ID: <20260717060743.105-1-jack4it@gmail.com> (raw)
In-Reply-To: <20260716113321.GA1636541@shredder>

On Thu, Jul 16, 2026 at 02:33:21PM +0300, Ido Schimmel wrote:
> OK, I understand. Each tenant has its own VNI, but it can have multiple
> HA sets on the same node and you want to distinguish between them using
> the UDP destination port.

Yes, that is exactly it.

> I don't particularly like NHA_FDB_PORT because it's an FDB-specific
> encapsulation attribute and these attributes naturally belong under
> NHA_ENCAP. That being said, I fail to see a better alternative given
> that FDB nexthops don't use NHA_ENCAP / LWT infra and probably
> shouldn't. [...]
> If you are going to post v2, please provide a more detailed motivation
> in the cover letter.

Understood, and I agree with the tension. I would not move FDB nexthops
onto NHA_ENCAP / LWT either, so I will keep the FDB-specific surface as
small as I can (see the VNI answer below). v2 will carry a fuller
motivation in the cover letter.

> In an earlier reply you wrote "shared inner MAC/IP". The "MAC" part was
> intentional because you need to load balance pure L2 traffic? IOW, if
> your traffic is only L3, can we do the load balancing using multipath
> routes in the overlay instead of using FDB nexthop groups?

Yes, the MAC was intentional, but not because the payload is pure L2,
it can be IP. The reason is that the whole HA set is addressed as one
anycast identity, a single overlay IP and MAC. That is deliberate. One
stable address keeps failover transparent, we just drop a dead replica
from the group with no client re-resolution. The address is also
consumed one layer up as a single stable endpoint, so giving each
replica its own IP would push multi-address handling and health
checking into that consumer, which is not available to us today.

> Related: What is the use case for NHA_FDB_VNI? In my experience, the VNI
> is only translated when routing traffic between tenants. Why do you need
> this in an FDB nexthop?

No strong use case, and your read matches mine. I will drop the
NHA_FDB_VNI mention from v2 rather than carry a speculative attribute
with no user.

Thanks again for the careful review.

Jack

      reply	other threads:[~2026-07-17  6:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-12 19:12 [PATCH net-next 0/3] net: nexthop: per-nexthop UDP dst port for fdb (VXLAN) nexthops Jack Ma
2026-07-12 19:12 ` [PATCH net-next 1/3] net: nexthop: add NHA_FDB_PORT for fdb nexthops Jack Ma
2026-07-12 19:12 ` [PATCH net-next 2/3] vxlan: honor per-nexthop fdb destination port Jack Ma
2026-07-12 19:12 ` [PATCH net-next 3/3] selftests: net: add coverage for fdb nexthop dst port Jack Ma
2026-07-13 12:23 ` [PATCH net-next 0/3] net: nexthop: per-nexthop UDP dst port for fdb (VXLAN) nexthops Ido Schimmel
2026-07-14  3:43   ` Jack Ma
2026-07-14 17:42     ` Ido Schimmel
2026-07-15  7:43       ` Jack Ma
2026-07-16 11:33         ` Ido Schimmel
2026-07-17  6:07           ` Jack Ma [this message]

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=20260717060743.105-1-jack4it@gmail.com \
    --to=jack4it@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=shuah@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.