Back from PTO

Back from PTO

[Doug Ledford]

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

As people know, I've had some paternity leave here as of late.  Then
there was the annual shutdown at Red Hat for the holidays, and then I
had some PTO on the back end of that.  As a result, I've been absent for
a while.  I don't like to pre-announce these things on public mailing
lists (nothing like telling the whole world when you will be away from
home to make you feel safe about your home while you're gone), but I
don't mind letting people know where I've been now that I'm back.

Obviously I'm behind.  I'm going to send in a pull request shortly with
the things that I had before I left on break.  I didn't get everything
into my for-next tag that I wanted to before I left on break, so I
expect there will be a second pull request that includes at least a
couple larger items I was working on when I left that should be about
the same now as they were before:

RoCEv2 support
mlx5 RoCE support
mlx4 RoCEv2 support
rdmavt
qib->rdmavt changes

Things that I intended to submit after the merge window opened and
Greg's merge was done:

Retake staging/rdma
Delete staging/rdma/{amso1100,ehca,ipath}
hfi1->rdmavt changes
Add staging/rdma/soft-rxe

Along the way, I may pick up some other commits too.  If you haven't
seen your desired commit(s) that you think should make it into 4.5 (like
the [v2] IB/core: sysfs.c: Fix PerfMgt ClassPortInfo handling patch that
isn't in yet but needs to be), please send me an email *offlist* (this
is important for my mail filtering that the list not be in the to/cc
address, you can bcc if you want) and include a link to the patch or
patches, preferably as a link to the latest version in patchworks versus
say a link to a mailing list archive of the submission email.

Thanks!

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



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

Re: Back from PTO

[Moni Shoua]

On Mon, Jan 18, 2016 at 11:22 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> As people know, I've had some paternity leave here as of late.  Then
> there was the annual shutdown at Red Hat for the holidays, and then I
> had some PTO on the back end of that.  As a result, I've been absent for
> a while.  I don't like to pre-announce these things on public mailing
> lists (nothing like telling the whole world when you will be away from
> home to make you feel safe about your home while you're gone), but I
> don't mind letting people know where I've been now that I'm back.
>
> Obviously I'm behind.  I'm going to send in a pull request shortly with
> the things that I had before I left on break.  I didn't get everything
> into my for-next tag that I wanted to before I left on break, so I
> expect there will be a second pull request that includes at least a
> couple larger items I was working on when I left that should be about
> the same now as they were before:
>
> RoCEv2 support
> mlx5 RoCE support
> mlx4 RoCEv2 support
> rdmavt
> qib->rdmavt changes
>
> Things that I intended to submit after the merge window opened and
> Greg's merge was done:
>
> Retake staging/rdma
> Delete staging/rdma/{amso1100,ehca,ipath}
> hfi1->rdmavt changes
> Add staging/rdma/soft-rxe
>
Doug,
it's not clear if you intend to take rdmavt into drivers/infiniband/sw
IMHO such a central piece of code needs to go through proper design
stages, be written with a clear and sharp interface and be published
with documentation.
To me it looks like the only purpose of rdmavt is to pull hfi1 driver
out from staging. If we want it as an infrastructure for any kind of
low level driver it needs to stick to infrastructure standards.
I hope that you agree

> Along the way, I may pick up some other commits too.  If you haven't
> seen your desired commit(s) that you think should make it into 4.5 (like
> the [v2] IB/core: sysfs.c: Fix PerfMgt ClassPortInfo handling patch that
> isn't in yet but needs to be), please send me an email *offlist* (this
> is important for my mail filtering that the list not be in the to/cc
> address, you can bcc if you want) and include a link to the patch or
> patches, preferably as a link to the latest version in patchworks versus
> say a link to a mailing list archive of the submission email.
>
> Thanks!
>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>               GPG KeyID: 0E572FDD
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Back from PTO

[Doug Ledford]

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

On 01/19/2016 12:04 PM, Moni Shoua wrote:
> On Mon, Jan 18, 2016 at 11:22 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:

>> rdmavt
>> qib->rdmavt changes
>>
>> Things that I intended to submit after the merge window opened and
>> Greg's merge was done:
>>
>> Retake staging/rdma
>> Delete staging/rdma/{amso1100,ehca,ipath}
>> hfi1->rdmavt changes
>> Add staging/rdma/soft-rxe
>>
> Doug,
> it's not clear if you intend to take rdmavt into drivers/infiniband/sw

I had intended to.  However, on Jan 6th at roughly 1pm EST, Dennis
submitted v3 of his rdmavt patch set.  At roughly 2pm EST you submitted
a completely different, competing patchset that resides in the same
place in the filesystem, has the same name, but is 100% different
internally.  I know Intel and Mellanox have a hard time working
together, but geeze...

> IMHO such a central piece of code needs to go through proper design
> stages, be written with a clear and sharp interface and be published
> with documentation.

Yes, you've repeated this multiple times.  As this is a kernel internal
interface only, and a private one to the IB stack, we can be a bit more
flexible than you suggest here and do things a little more on the fly.

> To me it looks like the only purpose of rdmavt is to pull hfi1 driver
> out from staging.

That's obviously the piece that Intel cares about, sure.

> If we want it as an infrastructure for any kind of
> low level driver it needs to stick to infrastructure standards.

This statement is too vague for me to say anything constructive.

> I hope that you agree

Again, too vague to answer.

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



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