On 2/14/2020 8:08 AM, Jason Gunthorpe wrote: > 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? > Correct. > Jason >
