Re: [for-next V3 00/15][PULL request] Mellanox mlx5 core driver updates 2016-08-20

[Leon Romanovsky <leonro@mellanox.com>]

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

On Tue, Aug 23, 2016 at 07:10:53PM +0300, Saeed Mahameed wrote:
> On Tue, Aug 23, 2016 at 6:57 PM, Doug Ledford <dledford@redhat.com> wrote:
> > On 8/23/2016 4:49 AM, Saeed Mahameed wrote:
> >> Hi Dave and Doug,
> >>
> >> This series contains several low level and API updates for mlx5 core
> >> commands interface and mlx5_ifc.h to be shared as base code for net-next and
> >> rdma mlx5 4.9 submissions.
> >>
> >> From Saeed, ten patches that refactors old layouts of firmware commands which
> >> were manually generated before we introduced the mlx5_ifc, now all of the firmware
> >> commands inbox/outbox layouts moved to use mlx5_ifc and we remove the old
> >> manually generated structures.
> >
> > These all looked fine to me.
> >
> >> Plus to those ten patches, we add two patches
> >> that unifies mlx5 commands execution interface and improve the driver log messages
> >> in that area.
> >
> > These are the patches that made my eyes want to bleed.  But, since it's
> > all changes to the mailbox commands being sent to your device, they are
> > easy to verify operationally, so I only gave these a cursory review and
> > expect if any of your commands broke because of this you'll be
> > submitting fixes ASAP.
> >
> 
> Thanks Doug for your review those patches already passed all kinds of
> our internal regression testings.
> What is nice about those patches is that they remove  ~1K  LOC from
> driver and unify the command interface.

Thanks for taking them.
One of the reasons for such a long delay of shared code submission was our
desire to take extra care and test these patches again and again.

> 
> >
> >> From Hadar and Ilya, added the needed hardware bits and infrastructure for
> >> minimum inline headers setting and encap/decap commands and capabilities,
> >> needed for E-Switch offloads.
> >
> > These looked fine to me, but aren't really in the RDMA area anyway.

Our internal goal is to have 0-merge conflicts between RDMA and net
trees.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]