On Mon, Apr 29, 2019 at 11:34:41AM +0300, Leon Romanovsky wrote:
> From: Mark Zhang
>
> Add an API to support set/clear per-port auto mode.
>
> Signed-off-by: Mark Zhang
> Reviewed-by: Majd Dibbiny
> Signed-off-by: Leon Romanovsky
> drivers/infiniband/core/Makefile | 2 +-
> drivers/infin
On Mon, Apr 29, 2019 at 11:34:49AM +0300, Leon Romanovsky wrote:
> From: Mark Zhang
>
> Since a QP can only be bound to one counter, then if it is bound to a
> separate counter, for backward compatibility purpose, the statistic
> value must be:
> * stat of default counter
> + stat of all running
On Mon, Apr 29, 2019 at 11:34:42AM +0300, Leon Romanovsky wrote:
> void rdma_counter_init(struct ib_device *dev)
> {
> struct rdma_port_counter *port_counter;
> diff --git a/drivers/infiniband/core/device.c
> b/drivers/infiniband/core/device.c
> index 9204b4251fc8..dfaa57de871f 100644
> +
On Mon, Apr 29, 2019 at 11:34:42AM +0300, Leon Romanovsky wrote:
> +/**
> + * rdma_counter_unbind_qp - Unbind a qp from a counter
> + * @force:
> + * true - Decrease the counter ref-count anyway (e.g., qp destroy)
> + */
> +int rdma_counter_unbind_qp(struct ib_qp *qp, bool force)
> +{
> + st
On Mon, Apr 29, 2019 at 11:34:47AM +0300, Leon Romanovsky wrote:
> From: Mark Zhang
>
> This patch adds the ability to return all available counters
> together with their properties and hwstats.
>
> Signed-off-by: Mark Zhang
> Reviewed-by: Majd Dibbiny
> Signed-off-by: Leon Romanovsky
> driv
On Mon, Apr 29, 2019 at 11:34:47AM +0300, Leon Romanovsky wrote:
> From: Mark Zhang
>
> This patch adds the ability to return all available counters
> together with their properties and hwstats.
>
> Signed-off-by: Mark Zhang
> Reviewed-by: Majd Dibbiny
> Signed-off-by: Leon Romanovsky
> driv
On Mon, Apr 29, 2019 at 11:34:49AM +0300, Leon Romanovsky wrote:
> diff --git a/drivers/infiniband/core/device.c
> b/drivers/infiniband/core/device.c
> index c56ffc61ab1e..8ae4906a60e7 100644
> +++ b/drivers/infiniband/core/device.c
> @@ -1255,7 +1255,11 @@ int ib_register_device(struct ib_device
On Mon, Apr 29, 2019 at 11:34:53AM +0300, Leon Romanovsky wrote:
> From: Mark Zhang
>
> This patch adds the ability to return the hwstats of per-port default
> counters (which can also be queried through sysfs nodes).
>
> Signed-off-by: Mark Zhang
> Signed-off-by: Leon Romanovsky
> drivers/in
On Mon, Apr 29, 2019 at 11:34:36AM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Changelog:
> v1 -> v2:
> * Rebased to latest rdma-next
> v0 -> v1:
> * Changed wording of counter comment
> * Removed unneeded assignments
> * Added extra patch to present global counters
>
> * I
On Wed, May 29, 2019 at 02:15:44PM +0300, Leon Romanovsky wrote:
> On Wed, May 22, 2019 at 02:10:42PM -0300, Jason Gunthorpe wrote:
> > On Mon, Apr 29, 2019 at 11:34:49AM +0300, Leon Romanovsky wrote:
> > > From: Mark Zhang
> > >
> > > Since a QP can only be
On Wed, May 29, 2019 at 02:05:24PM +0300, Leon Romanovsky wrote:
> On Wed, May 22, 2019 at 02:26:36PM -0300, Jason Gunthorpe wrote:
> > On Mon, Apr 29, 2019 at 11:34:49AM +0300, Leon Romanovsky wrote:
> > > diff --git a/drivers/infiniband/core/device.c
> > > b/drive
On Thu, Jun 06, 2019 at 10:19:41AM +0300, Max Gurtovoy wrote:
> > > Solution:
> > > - Common logic is declared in include/linux/dim.h and implemented in
> > >lib/dim/dim.c
> > > - Net DIM (existing) logic is declared in include/linux/net_dim.h and
> > >implemented in lib/dim/net_dim.c, whic
On Fri, Jun 07, 2019 at 06:14:11PM +, Saeed Mahameed wrote:
> On Thu, 2019-06-06 at 13:07 +0000, Jason Gunthorpe wrote:
> > On Thu, Jun 06, 2019 at 10:19:41AM +0300, Max Gurtovoy wrote:
> > > > > Solution:
> > > > > - Common logic is declared in include/l
On Tue, Jul 09, 2019 at 05:17:30PM +0300, Michal Kalderon wrote:
> Create some common API's for adding entries to a xa_mmap.
> Searching for an entry and freeing one.
>
> The code was copied from the efa driver almost as is, just renamed
> function to be generic and not efa specific.
>
> Signed-o
On Tue, Jul 09, 2019 at 05:17:34PM +0300, Michal Kalderon wrote:
> +static int qedr_init_user_db_rec(struct ib_udata *udata,
> + struct qedr_dev *dev, struct qedr_userq *q,
> + bool requires_db_rec)
> +{
> + struct qedr_ucontext *uctx =
On Tue, Jul 09, 2019 at 05:17:29PM +0300, Michal Kalderon wrote:
> This patch series uses the doorbell overflow recovery mechanism
> introduced in
> commit 36907cd5cd72 ("qed: Add doorbell overflow recovery mechanism")
> for rdma ( RoCE and iWARP )
>
> The first three patches modify the core code
On Tue, Jul 09, 2019 at 05:17:33PM +0300, Michal Kalderon wrote:
> Several casts were required around dpi_addr parameter in qed_rdma_if.h
> This is an address on the doorbell bar and should therefore be marked
> with __iomem.
>
> Reported-by: Jason Gunthorpe
> Signed-o
On Thu, Jul 25, 2019 at 07:34:15PM +, Michal Kalderon wrote:
> > > + ibdev_dbg(ucontext->device,
> > > + "mmap: obj[0x%p] key[%#llx] addr[%#llx] len[%#llx]
> > removed\n",
> > > + entry->obj, key, entry->address, entry->length);
> > > +
> > > + return entry;
> > > +}
> > > +
On Fri, Jul 26, 2019 at 08:42:07AM +, Michal Kalderon wrote:
> > > But we don't free entires from the xa_array ( only when ucontext is
> > > destroyed) so how will There be an empty element after we wrap ?
> >
> > Oh!
> >
> > That should be fixed up too, in the general case if a user is
> >
On Mon, Jul 29, 2019 at 04:53:38PM +0300, Gal Pressman wrote:
> On 29/07/2019 15:58, Michal Kalderon wrote:
> >> From: linux-rdma-ow...@vger.kernel.org >> ow...@vger.kernel.org> On Behalf Of Jason Gunthorpe
> >>
> >>> + xa_lock(&ucontext->
On Sun, Jul 28, 2019 at 11:45:56AM +0300, Gal Pressman wrote:
> On 26/07/2019 16:23, Jason Gunthorpe wrote:
> > On Fri, Jul 26, 2019 at 08:42:07AM +, Michal Kalderon wrote:
> >
> >>>> But we don't free entires from the xa_array ( only when ucontext is
> &
On Sun, Jul 28, 2019 at 12:30:51PM +0300, Kamal Heib wrote:
> > Maybe put this in ib_core_uverbs.c ?
> >
> > Kamal, you've been tackling various cleanups, maybe making ib_uverbs
> > unloadable again is something you'd be keen on?
> >
>
> Yes, Could you please give some background on that?
Most o
On Thu, Aug 01, 2019 at 03:21:36PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> From Michael,
>
> The series adds support for on-demand paging for DC transport.
> Adding handling of DC WQE parsing upon page faults and exposing
> capabilities.
>
> As DC is mlx-only transport, the ca
On Thu, Aug 01, 2019 at 03:21:37PM +0300, Leon Romanovsky wrote:
> diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
> index ec571fd7fcf8..5eae8d734435 100644
> +++ b/include/linux/mlx5/mlx5_ifc.h
> @@ -944,7 +944,9 @@ struct mlx5_ifc_odp_cap_bits {
>
> struct mlx5
On Thu, Jan 14, 2021 at 08:40:14AM -0800, Alexander Duyck wrote:
> Where I think you and I disagree is that I really think the MSI-X
> table size should be fixed at one value for the life of the VF.
> Instead of changing the table size it should be the number of vectors
> that are functional that
On Thu, Jan 14, 2021 at 09:55:24AM -0800, Alexander Duyck wrote:
> On Thu, Jan 14, 2021 at 8:49 AM Jason Gunthorpe wrote:
> >
> > On Thu, Jan 14, 2021 at 08:40:14AM -0800, Alexander Duyck wrote:
> >
> > > Where I think you and I disagree is that I really think the MS
On Thu, Jan 14, 2021 at 11:24:12AM -0800, Alexander Duyck wrote:
> > As you say BAR and MSI vector table are not so different, it seems
> > perfectly in line with current PCI sig thinking to allow resizing the
> > MSI as well
>
> The resizing of a BAR has an extended capability that goes with it
On Thu, Jan 14, 2021 at 01:43:57PM -0800, Alexander Duyck wrote:
> > > In addition Leon still hasn't answered my question on preventing the
> > > VF driver from altering entries beyond the ones listed in the table.
> >
> > Of course this is blocked, the FW completely revokes the HW resource
> > ba
On Thu, Jan 14, 2021 at 05:56:20PM -0800, Alexander Duyck wrote:
> That said, it only works at the driver level. So if the firmware is
> the one that is having to do this it also occured to me that if this
> update happened on FLR that would probably be preferred.
FLR is not free, I'd prefer not
On Fri, Jan 15, 2021 at 08:32:19PM -0800, Alexander Duyck wrote:
> On Fri, Jan 15, 2021 at 6:06 AM Jason Gunthorpe wrote:
> >
> > On Thu, Jan 14, 2021 at 05:56:20PM -0800, Alexander Duyck wrote:
> >
> > > That said, it only works at the driver level. So if the fir
On Sun, Jan 17, 2021 at 11:26:33AM +0200, Leon Romanovsky wrote:
> From: Parav Pandit
>
> This reverts commit fbdd0049d98d44914fc57d4b91f867f4996c787b.
>
> Due to commit in fixes tag, netdevice events were received only
> in one net namespace of mlx5_core_dev. Due to this when netdevice
> events
On Thu, Jan 21, 2021 at 12:59:55PM -0800, Samudrala, Sridhar wrote:
> > + mlx5_core.sf.4
> > + (subfunction auxiliary device)
> > + /\
> > + / \
> > + /\
> > +/ \
> > +
On Tue, Dec 08, 2020 at 09:39:28PM +0200, Vladimir Oltean wrote:
> It is not clear what this lock protects. If the authors wanted to ensure
> that "dev" does not disappear, that is impossible, given the following
> code path:
>
> mlx4_ib_netdev_event (under RTNL mutex)
> -> mlx4_ib_scan_netdevs
>
On Tue, Dec 15, 2020 at 10:47:36AM -0800, Alexander Duyck wrote:
> > Jason and Saeed explained this in great detail few weeks back in v0 version
> > of the patchset at [1], [2] and [3].
> > I better not repeat all of it here again. Please go through it.
> > If you may want to read precursor to it
On Tue, Dec 15, 2020 at 01:41:04PM -0800, Alexander Duyck wrote:
> > not just devlink and switchdev, auxbus was also introduced to
> > standardize some of the interfaces.
>
> The auxbus is just there to make up for the fact that there isn't
> another bus type for this though. I would imagine othe
On Tue, Dec 15, 2020 at 05:12:33PM -0800, Edwin Peer wrote:
> 1) More than 256 SFs are possible: Maybe it's about time PCI-SIG
> addresses this limit for VFs?
They can't, the Bus/Device/Function is limited by protocol and
changing that would upend the entire PCI world.
Instead PCI-SIG said PASI
On Tue, Dec 15, 2020 at 06:19:18PM -0800, Alexander Duyck wrote:
> > > I would really like to see is a solid standardization of what this is.
> > > Otherwise the comparison is going to be made. Especially since a year
> > > ago Mellanox was pushing this as an mdev type interface.
> >
> > mdev was
On Tue, Dec 15, 2020 at 08:13:21PM -0800, Alexander Duyck wrote:
> > > Ugh, don't get me started on switchdev. The biggest issue as I see it
> > > with switchev is that you have to have a true switch in order to
> > > really be able to use it.
> >
> > That cuts both ways, suggesting HW with a true
On Wed, Dec 16, 2020 at 08:31:44AM -0800, Alexander Duyck wrote:
> You say this will scale better but I am not even sure about that. The
> fact is SR-IOV could scale to 256 VFs, but for networking I kind of
> doubt the limitation would have been the bus number and would more
> likely be issues wit
On Wed, Dec 16, 2020 at 11:27:32AM -0800, Alexander Duyck wrote:
> That has been the case for a long time. However it had been my
> experience that SR-IOV never scaled well to meet those needs and so it
> hadn't been used in such deployments.
Seems to be going quite well here, perhaps the applica
On Wed, Dec 16, 2020 at 02:53:07PM -0800, Alexander Duyck wrote:
> It isn't about the association, it is about who is handling the
> traffic. Going back to the macvlan model what we did is we had a group
> of rings on the device that would automatically forward unicast
> packets to the macvlan in
On Thu, Dec 17, 2020 at 10:48:48AM -0800, Alexander Duyck wrote:
> Just to clarify I am not with Intel, nor do I plan to work on any
> Intel drivers related to this.
Sure
> I disagree here. In my mind a design where two interfaces, which both
> exist in the kernel, have to go to hardware in ord
On Thu, Dec 17, 2020 at 01:05:03PM -0800, Alexander Duyck wrote:
> > I view the SW bypass path you are talking about similarly to
> > GSO/etc. It should be accessed by the HW driver as an optional service
> > provided by the core netdev, not implemented as some wrapper netdev
> > around a HW imple
On Fri, Dec 18, 2020 at 01:17:09PM +, Mark Brown wrote:
> As previously discussed this will need the auxilliary bus extending to
> support at least interrupts and possibly also general resources.
I thought the recent LWN article summed it up nicely, auxillary bus is
for gluing to subsystems t
On Fri, Dec 18, 2020 at 03:52:04PM +, Mark Brown wrote:
> On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote:
> > On Fri, Dec 18, 2020 at 01:17:09PM +, Mark Brown wrote:
>
> > > As previously discussed this will need the auxilliary bus extending to
&
On Fri, Dec 18, 2020 at 06:03:10PM +, Mark Brown wrote:
> On Fri, Dec 18, 2020 at 12:28:17PM -0400, Jason Gunthorpe wrote:
> > On Fri, Dec 18, 2020 at 03:52:04PM +, Mark Brown wrote:
> > > On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote:
>
> > &
On Fri, Dec 18, 2020 at 07:09:11PM +, Lee Jones wrote:
> ACPI, DT and MFD are not busses.
And yet ACPI and PNP have a bus:
extern struct bus_type acpi_bus_type;
extern struct bus_type pnp_bus_type;
Why? Because in the driver core if you subclass struct device and want
to bind drivers,
On Fri, Dec 18, 2020 at 11:22:12AM -0800, Alexander Duyck wrote:
> Also as far as the patch count complaints I have seen in a few threads
> I would be fine with splitting things up so that the devlink and aux
> device creation get handled in one set, and then we work out the
> details of mlx5 atta
On Fri, Dec 18, 2020 at 08:32:11PM +, Mark Brown wrote:
> > So, I strongly suspect, MFD should create mfd devices on a MFD bus
> > type.
>
> Historically people did try to create custom bus types, as I have
> pointed out before there was then pushback that these were duplicating
> the platfor
On Fri, Dec 18, 2020 at 10:16:58PM +0100, Alexandre Belloni wrote:
> But then again, what about non-enumerable devices on the PCI device? I
> feel this would exactly fit MFD. This is a collection of IPs that exist
> as standalone but in this case are grouped in a single device.
So, if mfd had a m
On Thu, Dec 03, 2020 at 04:06:24PM +0100, Greg KH wrote:
> > ...for all the independent drivers to have a common commit baseline. It
> > is not there yet pending Greg's Ack.
>
> I have been trying to carve out some time to review this. At my initial
> glance, I still have objections, so please,
On Fri, Dec 04, 2020 at 10:29:52AM -0800, Saeed Mahameed wrote:
> Hi Jakub, Jason
>
> This pull request is targeting net-next and rdma-next branches.
>
> This series provides mlx5 support for auxiliary bus devices.
>
> It starts with a merge commit of tag 'auxbus-5.11-rc1' from
> gregkh/driver-c
On Wed, Dec 09, 2020 at 09:04:46AM -0800, Jakub Kicinski wrote:
> On Wed, 9 Dec 2020 08:21:00 +0200 Leon Romanovsky wrote:
> > On Tue, Dec 08, 2020 at 11:22:26AM -0800, Jakub Kicinski wrote:
> > > On Mon, 7 Dec 2020 20:14:00 +0800 Zou Wei wrote:
> > > > Remove including that don't need it.
> > >
On Wed, Nov 18, 2020 at 11:03:24AM -0700, David Ahern wrote:
> With Connectx-4 Lx for example the netdev can have at most 63 queues
What netdev calls a queue is really a "can the device deliver
interrupts and packets to a given per-CPU queue" and covers a whole
spectrum of smaller limits like RSS
On Wed, Nov 18, 2020 at 12:36:26PM -0700, David Ahern wrote:
> On 11/18/20 11:38 AM, Jason Gunthorpe wrote:
> > On Wed, Nov 18, 2020 at 11:03:24AM -0700, David Ahern wrote:
> >
> >> With Connectx-4 Lx for example the netdev can have at most 63 queues
> >
> > W
On Wed, Nov 18, 2020 at 10:22:51PM -0800, Saeed Mahameed wrote:
> > I think the biggest missing piece in my understanding is what's the
> > technical difference between an SF and a VDPA device.
>
> Same difference as between a VF and netdev.
> SF == VF, so a full HW function.
> VDPA/RDMA/netdev/SC
On Thu, Nov 19, 2020 at 07:35:26PM -0800, Jakub Kicinski wrote:
> On Thu, 19 Nov 2020 10:00:17 -0400 Jason Gunthorpe wrote:
> > Finally, in the mlx5 model VDPA is just an "application". It asks the
> > device to create a 'RDMA' raw ethernet packet QP that is uses
On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
> IB/hfi1: Fix fall-through warnings for Clang
> IB/mlx4: Fix fall-through warnings for Clang
> IB/qedr: Fix fall-through warnings for Clang
> RDMA/mlx5: Fix fall-through warnings for Clang
I picked these four to the rdm
On Tue, Nov 24, 2020 at 09:12:19AM -0800, Jakub Kicinski wrote:
> On Sun, 22 Nov 2020 08:41:58 +0200 Eli Cohen wrote:
> > On Sat, Nov 21, 2020 at 04:01:55PM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 15:03:34 -0800 Saeed Mahameed wrote:
> > > > From: Eli Cohen
> > > >
> > > > Add a
On Tue, Nov 24, 2020 at 10:41:06AM -0800, Jakub Kicinski wrote:
> On Tue, 24 Nov 2020 14:02:10 -0400 Jason Gunthorpe wrote:
> > On Tue, Nov 24, 2020 at 09:12:19AM -0800, Jakub Kicinski wrote:
> > > On Sun, 22 Nov 2020 08:41:58 +0200 Eli Cohen wrote:
> > > > On S
On Wed, Nov 25, 2020 at 10:54:22AM -0800, Jakub Kicinski wrote:
> > RDMA covers a wide range of accelerated networking these days.. Where
> > else are you going to put this stuff in the kernel?
>
> IDK what else you got in there :) It's probably a case by case answer.
Hmm, yes, it seems endless
; > functionality for statistics handling.
> >
> > Signed-off-by: Heiner Kallweit
>
> RDMA folks, ack for merging via net-next?
Yes OK
Ack-by: Jason Gunthorpe
Jason
On Tue, Nov 17, 2020 at 09:11:20AM -0800, Jakub Kicinski wrote:
> > Just to refresh all our memory, we discussed and settled on the flow
> > in [2]; RFC [1] followed this discussion.
> >
> > vdpa tool of [3] can add one or more vdpa device(s) on top of already
> > spawned PF, VF, SF device.
>
>
On Mon, Dec 21, 2020 at 06:51:40PM +, Mark Brown wrote:
> > with some kind of inheritance scheme where platform device remained as
> > only instantiated directly in board files, while drivers could bind to
> > OF/DT/ACPI/FPGA/etc device instantiations with minimal duplication &
> > boilerplate
On Mon, Jan 04, 2021 at 09:19:30PM +, Mark Brown wrote:
> > Regardless of the shortcut to make everything a struct
> > platform_device, I think it was a mistake to put OF devices on
> > platform_bus. Those should have remained on some of_bus even if they
>
> Like I keep saying the same thing
On Mon, Jan 04, 2021 at 04:51:51PM -0800, Dan Williams wrote:
> On Mon, Jan 4, 2021 at 4:14 PM Jason Gunthorpe wrote:
> >
> > On Mon, Jan 04, 2021 at 09:19:30PM +, Mark Brown wrote:
> >
> >
> > > > Regardless of the shortcut to make everything a struct
On Mon, Jan 04, 2021 at 07:12:47PM -0800, Dan Williams wrote:
> I get that, but I'm fearing a gigantic bus_ops structure that has
> narrow helpers like ->gpio_count() that mean nothing to the many other
> clients of the bus. Maybe I'm overestimating the pressure there will
> be to widen the ops st
On Tue, Jan 05, 2021 at 01:42:56PM +, Mark Brown wrote:
> On Mon, Jan 04, 2021 at 08:13:41PM -0400, Jason Gunthorpe wrote:
> > On Mon, Jan 04, 2021 at 09:19:30PM +, Mark Brown wrote:
>
> > > Like I keep saying the same thing applies to all non-enumerable buses -
&
On Mon, Oct 19, 2020 at 08:27:36AM +0300, Leon Romanovsky wrote:
> From: Parav Pandit
>
> When a mlx5 core devlink instance is reloaded in different net
> namespace, its associated IB device is deleted and recreated.
>
> Example sequence is:
> $ ip netns add foo
> $ devlink dev reload pci/:0
On Mon, Oct 19, 2020 at 01:23:23PM +, Parav Pandit wrote:
> > > - err = register_netdevice_notifier(&dev->port[port_num].roce.nb);
> > > + err = register_netdevice_notifier_net(mlx5_core_net(dev->mdev),
> > > + &dev->port[port_num].roce.nb);
> >
> > This l
On Mon, Oct 19, 2020 at 12:42:15PM -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH wrote:
> >
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > > From: Tom Rix
> > >
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am won
ready held by the core code. This causes
ULPs using the 2nd method to deadlock.
Provide a rdma_connect_locked() and have all ULPs call it from their
handlers.
Reported-by: Guoqing Jiang
Fixes: 2a7cec538169 ("RDMA/cma: Fix locking for the RDMA_CM_CONNECT state"
Signed-off-by:
On Mon, Oct 26, 2020 at 03:43:59PM +0200, Parav Pandit wrote:
> When a mlx5 core devlink instance is reloaded in different net
> namespace, its associated IB device is deleted and recreated.
>
> Example sequence is:
> $ ip netns add foo
> $ devlink dev reload pci/:00:08.0 netns foo
> $ ip netn
On Tue, Oct 27, 2020 at 10:01:00AM +0800, Chao Leng wrote:
> > diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
> > index aad829a2b50d0f..f488dc5f4c2c61 100644
> > +++ b/drivers/nvme/host/rdma.c
> > @@ -1730,11 +1730,10 @@ static void nvme_rdma_process_nvme_rsp(struct
> > nvme_rdma
Fixes: 2a7cec538169 ("RDMA/cma: Fix locking for the RDMA_CM_CONNECT state")
Acked-by: Santosh Shilimkar
Acked-by: Jack Wang
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
drivers/infiniband/core/cma.c| 40 +---
drivers/infiniband/ulp/iser/is
On Tue, Oct 27, 2020 at 03:19:36PM +0200, Leon Romanovsky wrote:
> > +int rdma_connect_locked(struct rdma_cm_id *id,
> > + struct rdma_conn_param *conn_param)
> > {
> > struct rdma_id_private *id_priv =
> > container_of(id, struct rdma_id_private, id);
> > in
On Wed, Oct 28, 2020 at 11:19:14AM +0200, Maor Gottlieb wrote:
> > + struct rdma_conn_param *conn_param)
> > {
> > struct rdma_id_private *id_priv =
> > container_of(id, struct rdma_id_private, id);
> > int ret;
> > - mutex_lock(&id_priv->handler_mutex);
>
On Sun, Nov 01, 2020 at 10:15:37PM +0200, Leon Romanovsky wrote:
> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> index 6c218b47b9f1..5316e51e72d4 100644
> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> @@ -1,18 +1,27 @@
> // SPDX-License-Identifier: GPL-2.0 OR
On Thu, Nov 05, 2020 at 08:33:02AM +0100, gregkh wrote:
> > Were there any additional changes you wanted to see happen? I'll go
> > give the final set another once over, but David has been diligently
> > fixing up all the declared major issues so I expect to find at most
> > minor incremental fixup
On Thu, Nov 05, 2020 at 12:31:52PM -0800, Saeed Mahameed wrote:
> On Sun, 2020-11-01 at 22:15 +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky
> >
> > Move mlx5_vdpa IFC header file to the general include folder, so
> > mlx5_core will be able to reuse it to check if VDPA is supported
> > p
On Thu, Nov 05, 2020 at 12:59:20PM -0800, Saeed Mahameed wrote:
> 2. you can always load a driver without its underlying device existed.
> for example, you can load a pci device driver/module and it will load
> and wait for pci devices to pop up, the subsysetem infrastructure will
> match between
On Sun, Apr 18, 2021 at 12:09:16AM +0530, Devesh Sharma wrote:
> The host crash I indicated earlier is actually caused by patch 4 and
> not by patch 3 from this series. I spent time to root cause the
This makes a lot more sense.
The ulp_id stuff does need to go away as well though.
> problem an
On Sun, Apr 18, 2021 at 04:49:38PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> The two fixes are targeted to the -next. Maor's change fixes DM code
> that was accepted in this cycle and Parav's change doesn't qualify
> urgency of -rc8.
>
> Thanks
>
> Maor Gottlieb (1):
> RDMA/ml
On Thu, Feb 11, 2021 at 10:55:49AM +0200, Leon Romanovsky wrote:
> From: Tal Gilboa
>
> The traditional DevX CQ creation flow goes through mlx5_core_create_cq()
> which checks that the given EQN corresponds to an existing EQ. For some
> mlx5 devices this behaviour is too strict, they expect EQN a
On Tue, Feb 09, 2021 at 03:11:05PM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Add an extra timestamp format for mlx5_ib device.
>
> Thanks
>
> Aharon Landau (2):
> net/mlx5: Add new timestamp mode bits
> RDMA/mlx5: Fail QP creation if the device can not support the CQE TS
>
On Fri, Feb 12, 2021 at 01:09:20PM -0800, Saeed Mahameed wrote:
> On Fri, 2021-02-12 at 14:10 -0400, Jason Gunthorpe wrote:
> > On Tue, Feb 09, 2021 at 03:11:05PM +0200, Leon Romanovsky wrote:
> > > From: Leon Romanovsky
> > >
> > > Add an extra
On Fri, Feb 12, 2021 at 01:19:09PM -0800, Saeed Mahameed wrote:
> On Fri, 2021-02-12 at 17:14 -0400, Jason Gunthorpe wrote:
> > On Fri, Feb 12, 2021 at 01:09:20PM -0800, Saeed Mahameed wrote:
> > > On Fri, 2021-02-12 at 14:10 -0400, Jason Gunthorpe wrote:
> > > > On T
On Fri, Feb 12, 2021 at 02:30:37PM -0800, Saeed Mahameed wrote:
> From: Aharon Landau
>
> These fields declare which timestamp mode is supported by the device
> per RQ/SQ/QP.
>
> In addition add the ts_format field to the select the mode for
> RQ/SQ/QP.
>
> Signed-off-by: Aharon Landau
> Signe
On Tue, Feb 16, 2021 at 10:12:12AM -0600, Bjorn Helgaas wrote:
> > >
> > > But I still don't like the fact that we're calling
> > > sysfs_create_files() and sysfs_remove_files() directly. It makes
> > > complication and opportunities for errors.
> >
> > It is not different from any other code tha
On Wed, Feb 17, 2021 at 12:02:39PM -0600, Bjorn Helgaas wrote:
> > BTW, I asked more than once how these sysfs knobs should be handled
> > in the PCI/core.
>
> Thanks for the pointers. This is the first instance I can think of
> where we want to create PCI core sysfs files based on a driver
> bi
On Wed, Feb 17, 2021 at 02:28:35PM -0600, Bjorn Helgaas wrote:
> On Wed, Feb 17, 2021 at 03:25:22PM -0400, Jason Gunthorpe wrote:
> > On Wed, Feb 17, 2021 at 12:02:39PM -0600, Bjorn Helgaas wrote:
> >
> > > > BTW, I asked more than once how these sysfs knobs should be
On Mon, Mar 01, 2021 at 09:04:20AM +0200, Leon Romanovsky wrote:
> From: Mark Bloch
>
> Current code uses many different types when dealing with a port of a
> RDMA device: u8, unsigned int and u32. Switch to u32 to clean up the
> logic.
>
> This allows us to make (at least) the core view consist
On Fri, Mar 26, 2021 at 09:00:50AM -0700, Alexander Duyck wrote:
> On Thu, Mar 25, 2021 at 11:44 PM Leon Romanovsky wrote:
> >
> > On Thu, Mar 25, 2021 at 03:28:36PM -0300, Jason Gunthorpe wrote:
> > > On Thu, Mar 25, 2021 at 01:20:21PM -0500, Bjorn Helgaas wrote:
> &g
On Fri, Mar 26, 2021 at 12:08:31PM -0500, Bjorn Helgaas wrote:
> Leon has implemented a ton of variations, but I don't think having all
> the files in the PF directory was one of them.
If you promise this is the last of this bike painting adventure then
let's do it.
Jason
On Sat, Mar 27, 2021 at 02:29:00AM +0900, Keith Busch wrote:
> On Fri, Mar 26, 2021 at 12:08:31PM -0500, Bjorn Helgaas wrote:
> > I also want to resurrect your idea of associating
> > "sriov_vf_msix_count" with the PF instead of the VF. I really like
> > that idea, and it better reflects the way b
On Fri, Mar 26, 2021 at 11:50:44AM -0700, Alexander Duyck wrote:
> My concern would be that we are defining the user space interface.
> Once we have this working as a single operation I could see us having
> to support it that way going forward as somebody will script something
> not expecting an
On Mon, Mar 29, 2021 at 07:01:44AM -0700, Michael Chan wrote:
> On Mon, Mar 29, 2021 at 1:52 AM Leon Romanovsky wrote:
> >
> > From: Leon Romanovsky
> >
> > There is no need in any indirection complexity for one ULP user,
> > remove all this complexity in favour of direct calls to the exported
>
On Thu, Mar 25, 2021 at 08:10:13PM +, Saleem, Shiraz wrote:
> Maybe I am missing something but I see that a devlink hot reload is
> required to enforce the update? There isn't really a de-init
> required of PCI driver entities in this case for this rdma param.
> But only an unplug, plug of th
On Mon, Mar 29, 2021 at 08:29:49PM -0500, Bjorn Helgaas wrote:
> I think I misunderstood Greg's subdirectory comment. We already have
> directories like this:
Yes, IIRC, Greg's remark applies if you have to start creating
directories with manual kobjects.
> and aspm_ctrl_attr_group (for "link")
On Tue, Mar 30, 2021 at 10:00:19AM -0500, Bjorn Helgaas wrote:
> On Tue, Mar 30, 2021 at 10:57:38AM -0300, Jason Gunthorpe wrote:
> > On Mon, Mar 29, 2021 at 08:29:49PM -0500, Bjorn Helgaas wrote:
> >
> > > I think I misunderstood Greg's subdirectory comment. We a
1 - 100 of 754 matches
Mail list logo
