netdev - Re: [net-next v3 00/20][pull request] Intel Wired LAN Driver Updates 2019-12-09

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46ed855e75f9eda89118bfad9c6f7b16dd372c71.camel@intel.com>
Date:   Tue, 10 Dec 2019 11:23:32 -0800
From:   Jeff Kirsher <jeffrey.t.kirsher@...el.com>
To:     Jason Gunthorpe <jgg@...pe.ca>
Cc:     davem@...emloft.net, gregkh@...uxfoundation.org,
        netdev@...r.kernel.org, linux-rdma@...r.kernel.org,
        nhorman@...hat.com, sassmann@...hat.com, parav@...lanox.com
Subject: Re: [net-next v3 00/20][pull request] Intel Wired LAN Driver
 Updates 2019-12-09

On Tue, 2019-12-10 at 15:11 -0400, Jason Gunthorpe wrote:
> On Tue, Dec 10, 2019 at 10:41:54AM -0800, Jeff Kirsher wrote:
> > On Tue, 2019-12-10 at 14:25 -0400, Jason Gunthorpe wrote:
> > > On Tue, Dec 10, 2019 at 10:06:41AM -0800, Jeff Kirsher wrote:
> > > > > Please don't send new RDMA drivers in pull requests to net. This
> > > > > driver is completely unreviewed at this point.
> > > > 
> > > > This was done because you requested a for a single pull request in
> > > > an
> > > > earlier submission 9 months ago.  I am fine with breaking up
> > > > submission,
> > > > even though the RDMA driver would be dependent upon the virtual bus
> > > > and
> > > > LAN
> > > > driver changes.
> > > 
> > > If I said that I ment a single pull request *to RDMA* with Dave's
> > > acks
> > > on the net side, not a single pull request to net.
> > > 
> > > Given the growth of the net side changes this may be better to use a
> > > shared branch methodology.
> > 
> > I am open to any suggestions you have on submitting these changes that
> > has
> > the least amount of thrash for all the maintainers involved.
> > 
> > My concerns for submitting the network driver changes to the RDMA tree
> > is
> > that it will cause David Miller a headache when taking additional LAN
> > driver changes that would be affected by the changes that were taken
> > into
> > the RDMA tree.
> 
> If you send the PR to rdma then you must refrain from sending changes
> to net that would conflict with it.

Yeah, that will be tough, since we will have *literally* hundreds of
patches for the ice driver for the 5.6 kernel.

> 
> I also do not want a headache with conflicts to a huge rdma driver in
> net, so you cannot send it to -net.

Agreed, I do not want to cause you or David Miller any headaches.  It was
not clear on what additional changes the RDMA team would have once their
driver got upstream.

> Mellanox uses a shared branch approach now, it is working well but
> requires discipline to execute.

Wouldn't a shared branch cause issues for either you or David Miller to
pull from, since it has changes from the RDMA and net-next tree's?

> You can also send your changes to net, wait a cycle then send the rdma
> changes. IIRC one of the other drivers is working this way.

This sounds like the best option currently, since there is still a lot of
work being done in the ice driver.  Since Greg wanted to see driver
examples, using the virtual bus, I can send the RDMA driver patches as RFC
in future submissions.  This way, we can make sure the implementation is
acceptable and will be ready for submission, once the virtual bus and LAN
driver changes are accepted.

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)