Date:	Tue, 12 Apr 2016 08:36:21 +0300
From:	Or Gerlitz <gerlitz.or@...il.com>
To:	Leon Romanovsky <leon@...n.nu>
Cc:	Saeed Mahameed <saeedm@....mellanox.co.il>,
	Saeed Mahameed <saeedm@...lanox.com>,
	Matan Barak <matanb@...lanox.com>,
	Linux Netdev List <netdev@...r.kernel.org>,
	"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Doug Ledford <dledford@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	Leon Romanovsky <leonro@...lanox.com>,
	Tal Alon <talal@...lanox.com>
Subject: Re: [PATCH for-next 2/2] net/mlx5: Update mlx5_ifc hardware features

On Tue, Apr 12, 2016 at 8:15 AM, Leon Romanovsky <leon@...n.nu> wrote:
> On Tue, Apr 12, 2016 at 12:37:34AM +0300, Or Gerlitz wrote:
>> On Tue, Apr 12, 2016 at 12:24 AM, Saeed Mahameed
>> <saeedm@....mellanox.co.il> wrote:
>> > On Tue, Apr 12, 2016 at 12:17 AM, Or Gerlitz <gerlitz.or@...il.com> wrote:
>>
>> >> feature --> features
>>
>> > Correct, will fix.
>>
>> >>> * Add vport to steering commands for SRIOV ACL support
>> >>> * Add mlcr, pcmr and mcia registers for dump module EEPROM
>> >>> * Add support for FCS, baeacon led and disable_link bits to hca caps
>> >>> * Add CQE period mode bit in  CQ context for CQE based CQ
>> >>>   moderation support
>> >>> * Add umr SQ bit for fragmented memory registration
>> >>> * Add needed bits and caps for Striding RQ support
>>
>> >> AFAIK, all the above are features will go through net-next, what made
>> >> you anticipate conflicts with linux-rdma?
>>
>> > FCS bit is needed also for rdma, so we took the liberty of updating
>> > all the needed HW structs, bits, caps, etc ..
>> > at once for all mlx5 features planned for 4.7 regardless of rdma/net conflicts.
>>
>> The cover letter states that this series deals with shared code.
>>
>> I guess you might also could extend it a bit to deal also with code
>> that you suspect could lead to conflicts, but I don't see why it
>> evolved to that extent.
>
> Or,
> All these micro-optimizations on this shared file can potentially lead
> to undesired merge conflicts. Subsystem maintainers and Linus don't need to
> deal with these conflicts at all.

Leon,

Conflicts happens @ all times, life.

We (MLNX) didn't do a good job to minimize them as much as
possible on the 4.5 cycle (understatement) and did vast improvement
in the 4.6 cycle (one or two conflicts AFAIK and communicated  to Linus).

It's correct that Linus got really angry on these two conflicts but I have
communicated to him the fact that we did that improvement and we're talking
on two commits for a fairly large volume of patches, the response was, if you
do things right, we will happily keep working with you, people, go look.

I understand your desire to get it down to zero, but it's not gonna
work, pick another target.

For example, the networking community has a fairly large rc activity
(I would say 10-20x
vs rdma), so when Dave does his "merge-rebases" for net-next over net
and linus tree
(4-5 times in a release), he has to this way or another solve
conflicts, yes! ditto for
Linus during merge windows and to some extent in rc times too.

> It won't help to anyone to split this commit to more than one patch.

The commit change-log should make it clear what this is about, and it doesn't.
If you believe in something, state that clear, be precise.

As Saeed admitted the shared code in the commit spans maybe 2% of it.

The 1st commit deals with a field which is not used in the driver,
this is a cleanup
that you can do in rc (net) patch (remove the field all together) and
overall, w.o seeing
the down-stream patches that depend on the newly introduced fields,
how do you know there aren't such (unused) bits in the 2nd commit?

Or.

Powered by blists - more mailing lists