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

[Ido Schimmel <idosch@nvidia.com>]

On Wed, Jul 22, 2026 at 08:43:38AM -0600, David Ahern wrote:
> On 7/22/26 5:46 AM, Ido Schimmel wrote:
> > On Tue, Jul 21, 2026 at 10:29:50PM +0000, Jack Ma wrote:
> >> 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.