On Fri, Feb 14, 2020 at 03:11:48AM +0000, Parav Pandit wrote: > On 2/13/2020 7:30 AM, Jason Gunthorpe wrote: > > On Wed, Feb 12, 2020 at 09:26:29AM +0200, Leon Romanovsky wrote: > >> From: Parav Pandit <parav@xxxxxxxxxxxx> > >> > >> This reverts commit 219d2e9dfda9431b808c28d5efc74b404b95b638. > >> > >> Below flow requires cm_id_priv's destination address to be setup > >> before performing rdma_bind_addr(). > >> Without which, source port allocation for existing bind list fails > >> when port range is small, resulting into rdma_resolve_addr() > >> failure. > > > > I don't quite understands this - what is "when port range is small" ? > > > There is sysfs knob to reduce source port range to use for binding. > So it is easy to create the issue by reducing port range to handful of them. > > >> rdma_resolve_addr() > >> cma_bind_addr() > >> rdma_bind_addr() > >> cma_get_port() > >> cma_alloc_any_port() > >> cma_port_is_unique() <- compared with zero daddr > > > > Do you understand why cma_port_is_unique is even testing the dst_addr? > > It seems very strange. > > ma_port_unique() reuses the source port as long as > destination is different (destination = either different > dest.addr or different dest.port between two cm_ids ). > > This behavior is synonymous to TCP also. > > > Outbound connections should not alias the source port in the first > > place?? > > > I believe it can because TCP seems to allow that too as long destination > is different. > > I think it allows if it results into different 4-tuple. So the issue here is if the dest is left as 0 then the cma_alloc_any_port() isn't able to alias source ports any more? Jason
