linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: davem@davemloft.net, gregkh@linuxfoundation.org,
	netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
	nhorman@redhat.com, sassmann@redhat.com, parav@mellanox.com
Subject: Re: [net-next v3 00/20][pull request] Intel Wired LAN Driver Updates 2019-12-09
Date: Tue, 10 Dec 2019 11:23:32 -0800	[thread overview]
Message-ID: <46ed855e75f9eda89118bfad9c6f7b16dd372c71.camel@intel.com> (raw)
In-Reply-To: <20191210191125.GG46@ziepe.ca>

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

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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2019-12-10 19:23 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-09 22:49 [net-next v3 00/20][pull request] Intel Wired LAN Driver Updates 2019-12-09 Jeff Kirsher
2019-12-09 22:49 ` [PATCH v3 01/20] virtual-bus: Implementation of Virtual Bus Jeff Kirsher
2019-12-10  6:49   ` Leon Romanovsky
2019-12-10 17:51     ` Jason Gunthorpe
2019-12-10 15:20   ` Greg KH
2019-12-10 18:22   ` Jason Gunthorpe
2019-12-09 22:49 ` [PATCH v3 02/20] ice: Initialize and register a virtual bus to provide RDMA Jeff Kirsher
2019-12-10 15:32   ` Greg KH
2019-12-23 19:06   ` Allan, Bruce W
2019-12-09 22:49 ` [PATCH v3 03/20] ice: Implement peer communications Jeff Kirsher
2019-12-09 22:49 ` [PATCH v3 04/20] i40e: Register a virtbus device to provide RDMA Jeff Kirsher
2019-12-10 15:33   ` Greg KH
2019-12-10 15:39   ` Greg KH
2019-12-13 23:08     ` Saleem, Shiraz
2019-12-14  8:37       ` Greg KH
2019-12-18 18:57         ` Saleem, Shiraz
2019-12-18 19:20           ` Jason Gunthorpe
2020-01-02 16:01             ` Saleem, Shiraz
2019-12-19  8:46           ` 'Greg KH'
2019-12-16  3:48     ` Parav Pandit
2019-12-16  7:15       ` Greg KH
2019-12-16  8:36         ` Parav Pandit
2019-12-16  8:58           ` Greg KH
2019-12-16  9:17             ` Parav Pandit
2019-12-09 22:49 ` [PATCH v3 05/20] RDMA/irdma: Add driver framework definitions Jeff Kirsher
2019-12-10 19:04   ` Jason Gunthorpe
2019-12-11  6:07     ` Leon Romanovsky
2019-12-12  1:40     ` Saleem, Shiraz
2019-12-12  8:39       ` Leon Romanovsky
2019-12-12  9:12         ` gregkh
2019-12-17 21:00       ` Jason Gunthorpe
2019-12-21  0:00   ` Keller, Jacob E
2019-12-09 22:49 ` [PATCH v3 06/20] RDMA/irdma: Implement device initialization definitions Jeff Kirsher
2019-12-09 22:49 ` [PATCH v3 07/20] RDMA/irdma: Implement HW Admin Queue OPs Jeff Kirsher
2019-12-09 22:49 ` [PATCH v3 08/20] RDMA/irdma: Add HMC backing store setup functions Jeff Kirsher
2019-12-09 22:49 ` [PATCH v3 09/20] RDMA/irdma: Add privileged UDA queue implementation Jeff Kirsher
2019-12-09 22:49 ` [PATCH v3 10/20] RDMA/irdma: Add QoS definitions Jeff Kirsher
2019-12-09 22:49 ` [PATCH v3 11/20] RDMA/irdma: Add connection manager Jeff Kirsher
2019-12-09 22:49 ` [PATCH v3 12/20] RDMA/irdma: Add PBLE resource manager Jeff Kirsher
2019-12-09 22:49 ` [PATCH v3 13/20] RDMA/irdma: Implement device supported verb APIs Jeff Kirsher
2019-12-09 22:49 ` [PATCH v3 14/20] RDMA/irdma: Add RoCEv2 UD OP support Jeff Kirsher
2019-12-09 22:49 ` [PATCH v3 15/20] RDMA/irdma: Add user/kernel shared libraries Jeff Kirsher
2019-12-09 22:49 ` [PATCH v3 16/20] RDMA/irdma: Add miscellaneous utility definitions Jeff Kirsher
2019-12-09 22:49 ` [PATCH v3 17/20] RDMA/irdma: Add dynamic tracing for CM Jeff Kirsher
2019-12-09 22:49 ` [PATCH v3 18/20] RDMA/irdma: Add ABI definitions Jeff Kirsher
2019-12-09 22:49 ` [PATCH v3 19/20] RDMA: Add irdma Kconfig/Makefile and remove i40iw Jeff Kirsher
2019-12-11 20:02   ` Jason Gunthorpe
2019-12-13 23:06     ` Saleem, Shiraz
2019-12-17 21:04       ` Jason Gunthorpe
2020-01-02 16:00         ` Saleem, Shiraz
2020-01-02 17:04           ` Jason Gunthorpe
2020-01-02 17:50             ` Saleem, Shiraz
2020-01-02 18:06               ` Jason Gunthorpe
2019-12-09 22:49 ` [PATCH v3 20/20] RDMA/irdma: Update MAINTAINERS file Jeff Kirsher
2019-12-10  7:33 ` [net-next v3 00/20][pull request] Intel Wired LAN Driver Updates 2019-12-09 Greg KH
2019-12-10 17:22 ` Jason Gunthorpe
2019-12-10 18:06   ` Jeff Kirsher
2019-12-10 18:25     ` Jason Gunthorpe
2019-12-10 18:41       ` Jeff Kirsher
2019-12-10 19:11         ` Jason Gunthorpe
2019-12-10 19:23           ` Jeff Kirsher [this message]
2019-12-10 19:44             ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46ed855e75f9eda89118bfad9c6f7b16dd372c71.camel@intel.com \
    --to=jeffrey.t.kirsher@intel.com \
    --cc=davem@davemloft.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jgg@ziepe.ca \
    --cc=linux-rdma@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@redhat.com \
    --cc=parav@mellanox.com \
    --cc=sassmann@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).