On Tue, 10 Dec 2019 01:02:08 +0100, Maciej Żenczykowski wrote:

quoted

Could you elaborate what protocols and products are in need of this
functionality?  

The ones I'm aware of are:
(a) Google's servers
(b) Android on at least some chipsets (Qualcomm at the bare minimum,
but I think it's pretty standard a solution) where there's a complex
port sharing scheme between the Linux kernel on the Application
Processor and the Firmware running on the modem (for ipv4 we only get
one ip address from the cellular carrier).  It's basically required
for things like wifi calling to work.

Okay, that's what I was suspecting.  It'd be great if the real
motivation for a patch was spelled out in the commit message :/

So some SoCs which run non-vanilla kernels require hacks to steal
ports from the networking stack for use by proprietary firmware.

I don't see how merging this patch benefits the community.

quoted

Why can't the NIC just get its own IP like it usually does with NCSI?  

Because often these nics are deployed as in place upgrades in
environments where there's a limited number of IPs.
Say a rack with a /27 ipv4 subnet (2**5 = 32 -> 29 usable ips, since
network/broadcast/gateway are burned) and 15+ pre-existing machines.
This means there's not enough IPs to assign separate ones for the nics.
Renumbering the rack, would imply renumbering the datacenter, etc...
And ipv4 - even RFC1918 - has long run out - so even in new
deployments there's not enough IPv4 ips to give to nics, and IPv6
isn't yet deployed *everywhere*.

So the conditions for this are:
 - in-place upgrade of an existing rack
 - IPv4 only
 - the existing servers didn't have NCSI or otherwise IPs for OOB
   control

Unlike the AP one this sounds like a very rare scenario..