From: Greg KH <gregkh@linuxfoundation.org>
To: "Saleem, Shiraz" <shiraz.saleem@intel.com>
Cc: "Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"Ertman, David M" <david.m.ertman@intel.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
"nhorman@redhat.com" <nhorman@redhat.com>,
"sassmann@redhat.com" <sassmann@redhat.com>,
"jgg@ziepe.ca" <jgg@ziepe.ca>,
"ranjani.sridharan@linux.intel.com"
<ranjani.sridharan@linux.intel.com>,
"pierre-louis.bossart@linux.intel.com"
<pierre-louis.bossart@linux.intel.com>,
"Nguyen, Anthony L" <anthony.l.nguyen@intel.com>,
"Bowers, AndrewX" <andrewx.bowers@intel.com>
Subject: Re: [net-next v3 2/9] ice: Create and register virtual bus for RDMA
Date: Thu, 7 May 2020 17:06:58 +0200 [thread overview]
Message-ID: <20200507150658.GA1886648@kroah.com> (raw)
In-Reply-To: <9DD61F30A802C4429A01CA4200E302A7DCD6B850@fmsmsx124.amr.corp.intel.com>
On Thu, May 07, 2020 at 02:04:04PM +0000, Saleem, Shiraz wrote:
> > Subject: Re: [net-next v3 2/9] ice: Create and register virtual bus for RDMA
> >
> > On Wed, May 06, 2020 at 02:04:58PM -0700, Jeff Kirsher wrote:
> > > From: Dave Ertman <david.m.ertman@intel.com>
> > >
> > > The RDMA block does not have its own PCI function, instead it must
> > > utilize the ice driver to gain access to the PCI device. Create a
> > > virtual bus device so the irdma driver can register a virtual bus
> > > driver to bind to it and receive device data. The device data contains
> > > all of the relevant information that the irdma peer will need to
> > > access this PF's IIDC API callbacks.
> >
> > But there is no virtual bus driver in this patch!
>
> Hi Greg -
>
> The irdma driver is the virtbus driver that would bind to the virtual devices created
> in this netdev driver.
Then why even have the virtbus code in this patch if there are no users?
And without any users, you are creating "virtbus devices" that live on
what bus? How does that work at all? Kind of defeats the purpose of a
virtual bus entirely if you do not use it, right?
> It is decoupled from this series as it was deemed in a prior discussion that irdma driver
> would go in a +1 cycle from net series to avoid conflicts. See discussion here --
> https://lore.kernel.org/netdev/46ed855e75f9eda89118bfad9c6f7b16dd372c71.camel@intel.com/
>
> The irdma driver is currently posted as an RFC series with its most recent submission here --
> https://lore.kernel.org/linux-rdma/20200417171251.1533371-1-jeffrey.t.kirsher@intel.com/
I can't accept that this series is using a virtual bus properly without
actually using the virtual bus driver code, can you?
If this is the case, it better be REALLY REALLY REALLY well documented
when one would, and would not, want to do that, as it doesn't make sense
to me...
thanks,
greg k-h
next prev parent reply other threads:[~2020-05-07 15:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-06 21:04 [net-next v3 0/9][pull request] 100GbE Intel Wired LAN Driver Updates 2020-05-05 Jeff Kirsher
2020-05-06 21:04 ` [net-next v3 1/9] Implementation of Virtual Bus Jeff Kirsher
2020-05-07 8:06 ` Greg KH
2020-05-06 21:04 ` [net-next v3 2/9] ice: Create and register virtual bus for RDMA Jeff Kirsher
2020-05-07 8:17 ` Greg KH
2020-05-07 14:04 ` Saleem, Shiraz
2020-05-07 15:06 ` Greg KH [this message]
2020-05-07 15:24 ` Edward Cree
2020-05-07 16:35 ` Greg KH
2020-05-06 21:04 ` [net-next v3 3/9] ice: Complete RDMA peer registration Jeff Kirsher
2020-05-06 21:05 ` [net-next v3 4/9] ice: Support resource allocation requests Jeff Kirsher
2020-05-06 21:05 ` [net-next v3 5/9] ice: Enable event notifications Jeff Kirsher
2020-05-06 21:05 ` [net-next v3 6/9] ice: Allow reset operations Jeff Kirsher
2020-05-06 21:05 ` [net-next v3 7/9] ice: Pass through communications to VF Jeff Kirsher
2020-05-06 21:05 ` [net-next v3 8/9] i40e: Move client header location Jeff Kirsher
2020-05-06 21:05 ` [net-next v3 9/9] i40e: Register a virtbus device to provide RDMA Jeff Kirsher
2020-05-07 7:00 ` [net-next v3 0/9][pull request] 100GbE Intel Wired LAN Driver Updates 2020-05-05 Greg KH
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=20200507150658.GA1886648@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=andrewx.bowers@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=david.m.ertman@intel.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jgg@ziepe.ca \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nhorman@redhat.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=ranjani.sridharan@linux.intel.com \
--cc=sassmann@redhat.com \
--cc=shiraz.saleem@intel.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).