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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 03, 2017 at 08:42:39AM -0400, Doug Ledford wrote:
> On Thu, 2017-08-03 at 08:22 -0400, Doug Ledford wrote:
> > On Thu, 2017-08-03 at 08:10 +0300, Leon Romanovsky wrote:
> > >
> > > Because, I truly believe that they proposed the nasty hack, which
> > > doesn't fix the real problem - inability to deal with losses of
> > > netlink
> > > messages.
> >
> > In so much as the iwpmd needs to be modified to do a resync, I agree
> > with you.  But, the fix they made caused the system to be "reliable
> > enough" that the problem more or less disappeared.  It is true that,
> > given enough load, the problem could resurface, but that hasn't
> > happened yet in the real world.
> >
> > However, iwpmd is part of rdma-core now, so *anyone* can fix it to do
> > the resyncs as needed (and I don't know, maybe it does, I just did a
> > quick grep for ENOBUFS to see if they capture that error and do a
> > resync on it, and saw no hits for that with grep).
>
> And in case this didn't sink in from the above statement, allow me to
> make it explicit:
>
> Does it not strike you how much of a failure it was on your part to
> submit a kernel patch that breaks iwpmd, code that is now part of rdma-
> core, FOR WHICH YOU ARE COMAINTAINER, without the corresponding patches
> to rdma-core to fix the real issue?  You don't get to tell Chien to "go
> fix his software" because his software is part of rdma-core for which
> you are co-maintainer and ultimately you bear responsibility for rdma-
> core as a whole whether Chien fixes his stuff or not!  Your job is to
> make sure that rdma-core is never broken in the way you were going to
> break it.  You had a conflict of interest here between your kernel work
> and your user space responsibilities and you did not choose well how to
> resolve that conflict.

Ohh, my god.

Doug,
There is no ANY breakage of UAPI and this was used as an argument
without ANY supportive claim behind of it. Just for the fun, I used the
same claim, but it looks like I was supposed to cut it once it was
claimed and not silently skip.

The iwpmd in rdma-core didn't get ANY patches BEFORE the patch in question
and AFTER.

So yes, I do responsible for the rdma-core and I'm enforcing the same policy
as we are using kernel - push companies to fix the root cause
and invest in the common infrastructure.

Chien is supported by huge corporation with many developers working on iWARP stack
and it seems very natural to demand from them the right solution.

Publicly, I tried it twice for the rdma-core:
1. One company stepped extra mile and improved the infrastructure.
2. Another company vanished into the dark and their supper important
feature wasn't so important at the end.

Thanks

>
> --
> Doug Ledford <dledford@xxxxxxxxxx>
>     GPG KeyID: B826A3330E572FDD
>     Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
>

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux