lkml.org 
[lkml]   [2016]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PULL REQUEST] Please pull rdma.git
From
Date
On 11/17/2016 5:24 PM, Or Gerlitz wrote:
> On Thu, Nov 17, 2016 at 9:44 PM, Doug Ledford <dledford@redhat.com> wrote:
>> On 11/17/16 1:49 PM, Leon Romanovsky wrote:
>>> On Thu, Nov 17, 2016 at 07:13:54AM -0500, Doug Ledford wrote:
>>>> Hi Linus,
>>>>
>>>> Due to various issues, I've been away and couldn't send a pull request
>>>> for about three weeks. There were a number of -rc patches that built up
>>>> in the meantime (some where there already from the early -rc stages).
>>>> Obviously, there were way too many to send now, so I tried to pare the
>>>> list down to the more important patches for the -rc cycle.
>
> Hi Doug,
>
> Except for the hfi1 patches, all the rest (core, mlx5, mlx4 and rxe)
> are marked now as only 21 hours old in your 4.9-rc branch and they
> seems be made from you picking partial subsets of multiple series,

Correct.

> with none of them acked by you on the list.

I had an all day meeting today and had to get out the door early. The
patches will be responded to.

> If you agree that I am describing things correctly - how are we
> expected to follow on your patch picking? I find it sort of impossible
> and error prone.

When I started this I said the official, canonical source of information
on patches like this is patchworks. That still holds true. In this
case, I pulled the full series of patches into a single bundle, then
reviewed every patch individually. I checked for importance and
dependence on other patches. Those that I thought could be moved to
4.10 were moved into a new bundle and then removed from the existing
bundle. In this way, the patches were always in one or the other. When
I was done, I used git am on the two bundles and one into the 4.9-rc and
the other into a -next branch. In that way I made sure I didn't miss
any from the four series that I pulled. Finally, I used the bundles to
mark the patches as accepted in patchworks. By marking the entire
bundles as accepted, and not individual patches, it makes sure that what
I mark accepted is the same as what I ran git am on. So, if the patch
shows in patchworks as accepted, then I got it. If it doesn't, then I
missed it.

>>> Are you adding the rest to your for-next branch? We would like to have
>>> enough time to check that nothing is lost.
>
>> Yes, it's already there in the mlx-next branch on github.
>
> Re the patches there, this one
>
> IB/mlx4: Set traffic class in AH
>
> "Set traffic class within sl_tclass_flowlabel when create iboe AH.
> Without this the TOS value will be empty when running VLAN tagged
> traffic, because the TOS value is taken from the traffic class in the
> address handle attributes.
>
> Fixes: 9106c41 ('IB/mlx4: Fix SL to 802.1Q priority-bits mapping for IBoE')"
>
> claims to fix my commit, I have approached Leon and Co for
> clarifications/questions over the list on the patch and nothing was
> answered.

I agree with you. It doesn't fix your patch. The commit message can
still be fixed up.

> Please do not send it to Linus and wait for them to respond. I
> disagree that it fixes my commit b/c my commit was prior to when
> route-able RoCE was introduced and on that time TOS had no relation.

I agree. A better fix tag would be the commit that added RoCEv2 support.

> and this one
>
> "IB/mlx4: Put non zero value in max_ah device attribute
>
> Use INT_MAX since this is the max value the attribute can hold, though
> hardware capability is unlimited.
>
> Fixes: 225c7b1 ('IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters')"
>
> does a tiny enhancement for a 10y old commit of Roland, why you think
> we need it in 4.9-rc6 or 7??

I don't, it's in the mlx-next branch which means I'll queue it up for
the 4.10 merge window. I have no plan on sending that branch for 4.9-rc.

--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2016-11-18 03:02    [W:0.060 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site