Re: shrink struct ib_send_wr V4

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

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

On 11/02/2015 08:28 PM, Jason Gunthorpe wrote:
> On Mon, Nov 02, 2015 at 07:52:05PM -0500, Doug Ledford wrote:
>> It shouldn't be.  I reviewed those changes and they looked right (given
>> the limitations).  All you needed was to boot with nopat on the kernel
>> command line to get the old kernel behavior and it would continue to
>> work as before, and it would print out a message telling you to do so if
>> you hadn't already.
> 
> Alright, that was done after it was pretty clear the driver was
> useless and I stopped looking at that part of the series. I don't know
> why we made Luis jump through such hoops instead of just deleting it
> right then and there.
> 
>>> For amso1100, kernel ULPs has never been its target.  Didn't we only
>>> recently got any support for iWARP in iSER?
> 
> I don't like that reasoning. In 4.4 we expect some ULPs to work on
> iWarp, and amso110 can't do it. That is a big reason why the driver
> is getting chopped.
> 
>>> The reason I lobbied to get rid of them is specifically because they
>>> don't work and maintaining them (ie the driver and the single-use ULP
>>> codepath side) is a huge pain. Keeping them around and keeping them
>>> compiling defeats the entire point. Just delete them, we don't need to
>>> wait for 4.6.
>>
>> That's not true.  User space continues to work, and amso1100 shouldn't
>> be greatly negatively impacted by recent changes.  Nor should ipath.
> 
> So what if user space works? The kernel consumers are known broken.

No, one kernel consumer that never worked on iWARP before now works on a
different iWARP controller but doesn't work on the old iWARP controller.
 Hardly the end of the world.

> We've commited to removing the driver from the kernel. We have support
> of the driver authors to do this. We have found no users or
> testers. We've committed to removing the ULP support (ie MR-only code
> is being ripped out).
> 
> *WHY* spend an ounce of time fixing up code that *NO-ONE* will ever
> even run? Wasted effort. Just delete them now.

You don't just "delete them now" because it denies anyone advanced
warning of the change and denies them the chance to speak up in
opposition to the driver's removal.  We queried the kernel community and
found no one using it.  There are a lot of users out there that don't
involve themselves in the kernel community at all.  For those users,
there is a normal push back mechanism that involves the change trickling
down into distros and then people complaining if they don't want the
drivers removed.  We could speed that push back cycle up if the various
distros proactively queried their customer's hardware usage.  But
without either a query activity or a push back cycle, your assertion
that "*NO-ONE* will ever even run?" is mere assumption not a statement
of fact.

I suspect you are right and we *could* delete them now without a
problem.  But without that push back cycle or a query to find out for
sure, you're asking me to take it on faith instead of doing due
diligence, and I don't have any intention of being called out later for
failing to do due diligence.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]