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. No preference on dst_port / DST_PORT versus other options
(NHA_FDB_UDP_PORT for example)
