Re: [PATCH rdma-next] Revert "IB/core: Add flow control to the portmapper netlink calls"

Leon Romanovsky
2017-06-05T04:00:30Z

[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]

On Sun, Jun 04, 2017 at 09:23:13PM -0500, Chien Tin Tung wrote:
> Sun, Jun 04, 2017 at 08:36:35AM +0300, Leon Romanovsky wrote:
> > On Fri, Jun 02, 2017 at 11:28:49AM -0500, Shiraz Saleem wrote:
> > > On Wed, May 31, 2017 at 02:10:31PM -0600, Bart Van Assche wrote:
> > > > On Wed, 2017-05-31 at 12:42 -0500, Shiraz Saleem wrote:
> > > > > > 5. I proposed a solution -> go and fix your user space program.
> > > > >
> > > > > This is a kernel patch you are trying to revert, you are breaking existing
> > > > > kernel functionality. Nothing to do with user space.
> > > > >
> > > > > Bottom line, come up with a solution that will address both port mapper
> > > > > functionality and your issue.
> > > >
> > > > Hello Shiraz,
> > > >
> > > > Sorry that this means additional work for you, but I agree with Leon that
> > > > user space software should not assume that netlink sockets are a reliable
> > > > communication mechanism.
> > >
> > > Hi Bart - Thank you for your response.
> > >
> > > The original problem was that ibnl_unicast, which is used to send nl messages from
> > > portmapper kernel space to user-space, would occasionally and momentarily fail under stress.
> > > We could have retried the call for a certain amount of time, but since netlink_unicast has a
> > > nonblock/block parameter, we chose to use the blocking option with a timeout. So we thought we
> > > did account for deadlocks with this timeout.
> >
> > Not really, you just reduced the chances. In very large scale, you will
> > have a very large chances of such deadlocks.
>
> Please stop using the word deadlock until you can prove that the deadlock exists with the timeout
> in place.

Can you please post the whole list of forbidden words? It will be great to
have it accompanied with technical response to my and Bart's claims, and
to summarize it, it is very simple: "netlink receive should be
non-blocking and asynchronous".

It will allow for all libnl functions, like nl_socket_set_nonblocking,
nl_recvmsgsa and nl_wait_for_ack, work correctly with ALL NETLINK_RDMA
clients.

Thanks

>
> Chien
>
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]