Re: [PATCH net-next v3 1/3] net: nexthop: add NHA_FDB_PORT for fdb nexthops

On Wed, Jul 22, 2026 at 08:43:38AM -0600, David Ahern wrote:

On 7/22/26 5:46 AM, Ido Schimmel wrote:

quoted

On Tue, Jul 21, 2026 at 10:29:50PM +0000, Jack Ma wrote:

quoted

Commit 1274e1cc4226 ("vxlan: ecmp support for mac fdb entries") lets a
single inner MAC be reached through a group of remote VTEPs, with the
kernel flow-hashing across the group members.  Each member carries its
own remote IP, but the UDP destination port is always taken from the
VXLAN device (vxlan->cfg.dst_port) and cannot be set per member.

Some deployments pack several receivers behind one underlay IP and tell
them apart by UDP port, so they need a per-nexthop destination port to
spread flows across (IP, port) tuples rather than IP alone.

Add a netlink attribute NHA_FDB_PORT (__be16, mirroring NDA_PORT) that
carries an optional UDP destination port on an fdb nexthop.  It is only
accepted together with NHA_FDB and NHA_GATEWAY; it is stored in struct
nh_info and echoed back on dump.  This patch is control-plane plumbing
only; the VXLAN datapath is wired up in a follow-up patch, so behaviour
is unchanged for now.

I looked more closely at the test and the iproute2 patch and wanted to
comment that "port" seems too generic given that the attribute is
specific to FDB nexthops and called NHA_FDB_PORT. It made me think that
maybe we should use a more generic attribute name (e.g., NHA_DST_PORT)
and a corresponding "dst_port" keyword in iproute2. We can still limit
this to FDB nexthops during validation, but in the unlikely case that we
will need a destination port for other nexthops, we could just reuse
this attribute. It's not like we have NHA_FDB_GATEWAY.

David, WDYT?

I was thinking along the same lines -- FDB_PORT can be confused with
bridge port.

I agree.

No preference on dst_port / DST_PORT versus other options
(NHA_FDB_UDP_PORT for example)

I don't see a reason to make the attribute overly specific (to UDP and
FDB), which is why I prefer DST_PORT.