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

Chien Tin Tung
2017-06-05T02:21:13Z

> I think that I understand the differences between our views on the subject. The main
> difference is if iWARP portmapper is part of large ecosystem (my view) or some
> standalone feature (your view).

Please do not speak for me.

Portmapper is a part of the ecosystem but the only user of it is on the iWARP side.
It is no different from iw_cm which is only used from iWARP side.

> I see iWARP as an integral part of IB core and I do expect that all consumers of
> NETLINK_RDMA will be complied to libnl library and work in similar manner to whole
> network stack. I do expect that newcomer won't learn in hard way that
> his non-blocking calls to netdev NETLINKs and NETLINK_RDMA work except
> for iWARP portmapper part.

You are trying to generalize portmapper into something which it is not to justify
your argument. Please stop this line of argument. It won't work on me.

> > > > > 4. Reverting is a common practice in Linux kernel. Patches are not
> > > > > carved in stones.
> > > >
> > > > Reverting a patch that's introduced during RC cycle is fine, introducing
> > > > regression is NOT and that is what you are doing by simply proposing to revert
> > > > this patch. Reverting this patch will introduce a REGRESSION error with respect to
> > > > port mapping functionality for all iWARP vendors.
> > >
> > > Interesting and how did all these iWARP vendors survive before your
> > > patch?
> >
> > We are all still here. :-) But if we let you simply revert a patch that fixes portmapper
> > for all iWARP vendors then we may be not.
>
> It is not really fixing but hiding, and it is not related to vendors which want
> or don't want, it is related to the community and to the right infrastructure for
> everyone, so everyone will benefit from it.

Again, over generalization.

> > > > > 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.
> >
> > Here is a better solution. Post a patch to the kernel that will not introduce a regression
> > and fix whatever the probelm you think there is, then I will personally review the patch.
>
> You got proposal, which is not related to kernel.

Still waiting on a usable patch from you, no more unsubstantiated arguments from you.

Chien