On Tue, 10 Dec 2019 01:02:08 +0100, Maciej Żenczykowski wrote: > > 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. > > 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..
