ach mcast
> has its dev as a member in the mcast struct.
Reviewed-by: Christoph Lameter <c...@linux.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 3 Jan 2016, ira.we...@intel.com wrote:
> Attributed ID was declared as an int while the value should really be big
> endian 16.
Reviewed-by: Christoph Lameter <c...@linux.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body
Reviewed-by: Christoph Lameter <c...@linux.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 21 Dec 2015, Hal Rosenstock wrote:
> > Don't we need to change all the sysfs_remove_groups to use
> > get_counter_table as
> > well?
>
> Looks like it to me too. Good catch.
Fix follows:
From: Christoph Lameter <c...@linux.com>
Subject: Fix sysfs entr
V2->V3: Add check for NOIETF mode and create special table
for that case.
Check if the extended counters are available and if so
create the proper extended and additional counters.
Reviewed-by: Hal Rosenstock <h...@mellanox.com>
Signed-off-by: Christoph Lameter <c...@linux.com&g
V2->V3
- Also add support for NOIETF counter mode where we have 64 bit
counters but not the multicast/unicast counters.
- Add Reviewed-by's from Hal.
V1->V2
- Add detection of the capability for 64 bit counter support
- Lots of improvements as a result of suggestions by Hal
Add the attr_id on port_table_attribute since we will have to add
a different port_table_attribute for the extended attribute soon.
Reviewed-by: Hal Rosenstock <h...@mellanox.com>
Signed-off-by: Christoph Lameter <c...@linux.com>
---
drivers/infiniband/core/sysfs.c | 7 +--
1 fil
Create a new function to retrieve performance management
data from the existing code in get_pma_counter().
Reviewed-by: Hal Rosenstock <h...@mellanox.com>
Signed-off-by: Christoph Lameter <c...@linux.com>
---
drivers/infiniband/core/sysfs.c | 62 ++---
ipoib_multicast.c for expiration of mc groups.
Reviewed-by: Iraq Weiny <ira.we...@intel.com>
Signed-off-by: Christoph Lameter <c...@linux.com>
---
drivers/infiniband/ulp/ipoib/ipoib.h | 3 +--
drivers/infiniband/ulp/ipoib/ipoib_main.c | 7 ++-
drivers/infiniba
V1->V2:
- Rename function as requested by Ira
Code cleanup to move multicast specific code that checks for
a sendonly join to ipoib_multicast.c. This allows the removal
of the export of __ipoib_mcast_find().
Signed-off-by: Christoph Lameter <c...@linux.com>
---
drivers/infin
V1->V2
- Add Reviewed by's for first patch from Ira Weiny
- Change name of ipoib_check_mcast_sendonly() to
ipoib_check_and_add_mcast_sendonly() as requested by Ira
This patchset cleans up the code a bit after the last round of multicast
patches related to the sendonly join logic. Some
On Mon, 21 Dec 2015, Leon Romanovsky wrote:
> On Mon, Dec 21, 2015 at 08:42:53AM -0600, Christoph Lameter wrote:
> > Code cleanup to remove multicast specific code from ipoib_main.c
> >
> > The removal of a list of multicast groups occurs in three places.
>
On Thu, 17 Dec 2015, Hal Rosenstock wrote:
> > + if (cpi.capability_mask && IB_PMA_CLASS_CAP_EXT_WIDTH) {
> > + /* We have extended counters */
> > +
> > + if (cpi.capability_mask && IB_PMA_CLASS_CAP_EXT_WIDTH_NOIETF)
> > + /* But not the IETF ones */
> > +
NOIETF means extended
> counters without IETF ones ([uni multi]cast [rcv xmit] pkts).
Ok so I updated the add on patch to the following. Doug: Is this enough
or do you want another rollup?
From: Christoph Lameter <c...@linux.com>
Subject: IB core counters: Support noietf extended counters
On Thu, 17 Dec 2015, Hal Rosenstock wrote:
> > + * Get a MAD block of data.
>
> Nit: Get PerfMgt MAD block of data
Ok.
> > + * Returns error code or the number of bytes retrieved.
> > + */
> > +static int get_mad(struct ib_device *dev, int port_num, int attr,
>
> Nit: Maybe this is too verbose
Add the attr_id on port_table_attribute since we will have to add
a different port_table_attribute for the extended attribute soon.
Signed-off-by: Christoph Lameter <c...@linux.com>
Index: linux/drivers/infiniband/core/s
V1->V2 Add detection of the capability for 64 bit counter support and lots
of improvements as a result of suggestions by Hal Rosenstock.
Currently we only use 32 bits for the packet and byte counters. There have been
extended countes available for some time but we have no support for those
yet
On Thu, 17 Dec 2015, Hal Rosenstock wrote:
> > I thought a port is always supplied since we get the info for a particular
> > port and the directory only exists if there is a port?
>
> Yes, but there is no port (PortSelect) field in ClassPortInfo attribute
> unlike the PortCounters and
On Thu, 17 Dec 2015, Hal Rosenstock wrote:
> > - ret = sysfs_create_group(>kobj, _group);
> > + ret = sysfs_create_group(>kobj,
> > + port_check_extended_counters(device) ?
> > + _group_ext :
>
> Would be nice to populate 2 different groups based on whether PMA
>
On Thu, 17 Dec 2015, Hal Rosenstock wrote:
> On 12/17/2015 4:28 PM, Christoph Lameter wrote:
> > So port_check_extended_counters need to return another value for this.
> > The IETF ones are the uni/mcast xxx counters?
>
> Yes
Ok. Then this patch on top of the last one shoul
Check if the extended counters are available and if so
create the proper extended and additional counters.
Signed-off-by: Christoph Lameter <c...@linux.com>
Index: linux/drivers/infiniband/core/sysfs.c
===
--- linux.orig/d
Create a new function to retrieve performance management
data from the existing code in get_pma_counter().
Signed-off-by: Christoph Lameter <c...@linux.com>
Index: linux/drivers/infiniband/core/sysfs.c
===
--- linux.orig/d
On Wed, 16 Dec 2015, Christoph Lameter wrote:
> DRAFT: This is missing the check if this device supports
> extended counters.
Found some time and here is the patch with the detection of the extended
attribute through sending a mad request. Untested. Got the info on how
to do the prop
On Tue, 15 Dec 2015, Doug Ledford wrote:
> On 12/15/2015 04:42 PM, Hal Rosenstock wrote:
> > On 12/15/2015 4:20 PM, Jason Gunthorpe wrote:
> >>> The unicast/multicast extended counters are not always supported -
> depends on setting of PerfMgt ClassPortInfo
>
o this would hopefully work if someone
would insert the proper check. Note that this patch no longer needs the
earlier 2 patches.
>From Christoph Lameter <c...@linux.com>
Subject: IB Core: Display extended counter set if available
Check if the extended counters are available and if so
creat
On Mon, 14 Dec 2015, Hal Rosenstock wrote:
> > Mellanox should really confirm this for their hardware matrix.
>
> I am trying to get definitive answer to this.
I was told today on a conf call with a couple of Mellanox employees that
extended counters are always available.
--
To unsubscribe from
On Mon, 14 Dec 2015, Weiny, Ira wrote:
> > How about
> >=20
> > ipoib_check_and_add_mcast_sendonly()
>
> Better.
Fixup patch:
Subject: ipoib: Fix up naming of ipoib_check_and_add_mcast_sendonly
Signed-off-by: Christoph Lameter <c...@linux.com>
Index
On Mon, 14 Dec 2015, Matan Barak wrote:
> > No idea what the counter is doing. Saw another EXT counter implementation
> > use 0 so I thought that was fine.
>
> It seems like a counter index, but I might be wrong though. If it is,
> don't we want to preserve the existing non-EXT schema for the new
On Fri, 11 Dec 2015, ira.weiny wrote:
> I think I would rather see this called something like
>
> ipoib_add_to_list_sendonly
>
> Or something...
>
> Calling it iboib_check* sounds like it should return a bool.
Hmm... It only adds the multicast group if the check was successful.
How about
On Mon, 14 Dec 2015, Matan Barak wrote:
> > +static PORT_PMA_ATTR(unicast_rcv_packets , 0, 64, 384,
> > IB_PMA_PORT_COUNTERS_EXT);
> > +static PORT_PMA_ATTR(multicast_xmit_packets, 0, 64, 448,
> > IB_PMA_PORT_COUNTERS_EXT);
> > +static PORT_PMA_ATTR(multicast_rcv_packets
Code cleanup to move multicast specific code that checks for
a sendonly join to ipoib_multicast.c. This allows the removal
of the export of __ipoib_mcast_find().
Signed-off-by: Christoph Lameter <c...@linux.com>
---
drivers/infiniband/ulp/ipoib/ipoib.h | 3 ++-
drivers/infiniba
ipoib_multicast.c for expiration of mc groups.
Signed-off-by: Christoph Lameter <c...@linux.com>
---
drivers/infiniband/ulp/ipoib/ipoib.h | 3 +--
drivers/infiniband/ulp/ipoib/ipoib_main.c | 7 ++-
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 24 ++---
This patchset cleans up the code a bit after the last round of multicast
patches related to the sendonly join logic. Some of the bits of code
landed in ipoib_main.c instead of ipoib_multicast.c.
- Move the multicast bits into that file so that everything is neatly together
- Reduce the number of
This is necessary to support the extended attributes which involves
a different attribute id.
Signed-off-by: Christoph Lameter <c...@linux.com>
---
drivers/infiniband/core/sysfs.c | 41 ++---
1 file changed, 22 insertions(+), 19 deletions(-)
diff
Currently we only use 32 bits for the packet and byte counters. There have been
extended countes available for some time but we have no support for those
yet upstream. We keep having issues with 32 bit counters wrapping. Especially
the byte counter can wrap frequently (as in multiple times per
counters then we will have to add some fallback
technique here.
Signed-off-by: Christoph Lameter <c...@linux.com>
---
drivers/infiniband/core/sysfs.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/core/sysfs.c b/drivers/infiniban
Add a branch to display 64 bit values
Signed-off-by: Christoph Lameter <c...@linux.com>
---
drivers/infiniband/core/sysfs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/infiniband/core/sysfs.c b/drivers/infiniband/core/sysfs.c
index 1c8716f..0083a4f 100644
--- a/d
On Tue, 1 Dec 2015, Or Gerlitz wrote:
> We're against into this... upstream is on 4.4-rc3 while your latest branch in
> kernel.org (the one that carries thefor-next tag) is rebased to 4.3-rc3...
Seems that everything was merged? So you can directly use 4.4-rc1
until he comes up with a for-next
On Tue, 24 Nov 2015, Anuj Kalia wrote:
> InfiniBand flow control is done at the link layer, so UD does not drop
> packets due to congestion.
Correct. But multicast packets are droped at the QP receive level if the
app does not provide enough buffers to accept the data stream. The
bufers can
On Wed, 25 Nov 2015, Peter Chinetti wrote:
> > Correct. But multicast packets are droped at the QP receive level if the
> > app does not provide enough buffers to accept the data stream. The
> > bufers can easily be overrun if one does not code carefully given that
> > the maximum number of those
On Sun, 15 Nov 2015, Matan Barak wrote:
> This series adds support for completion timestamp. In order to
> support this feature, several extended verbs were implemented
> (as instructed in libibverbs).
This is the portion that
implements timestaping for libmlx5 and this patchset depends on
On Wed, 21 Oct 2015, Or Gerlitz wrote:
> Again, the kernel stack consuming rate here was < 1 bit a year when
> averaging over time since this was introduced. So we should be doing
> well for the coming ~10-20 years with this 32 bit field, and we can
> easily extend it later, I verified that with
From: Christoph Lameter <c...@linux.com>
Subject: ipoib mcast sendonly join: Isolate common list remove code
Code cleanup to remove multicast specific code from ipoib_main.c
The removal of a list of multicast groups occurs in three places.
Create a new function ipoib_mcast_remove_list(
From: Christoph Lameter <c...@linux.com>
Subject: ipoib mcast sendonly join: Move multicast specific code out of
ipoib_main.c.
Code cleanup to move multicast specific code that checks for
a sendonly join to ipoib_multicast.c. This allows the removal
of the export of __ipoib_mcast_find().
On Thu, 15 Oct 2015, eran ben elisha wrote:
> I rebased the series due to a small conflict in
> drivers/net/ethernet/mellanox/mlx4/fw.c
The git trees also need rebasing on github.com.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to
On Wed, 26 Aug 2015, eran ben elisha wrote:
> > Do you have this in a git tree somewhere for testing?
>
> Yes,
> please pull from https://github.com/eranbenelisha/linux branch
> rebased-for-4.3/lb_prev
>
> If you with to get the user space as well for testing, please use:
>
we
do not free the mcast structure. This results in a memory leak.
Signed-off-by: Christoph Lameter <c...@linux.com>
Index: linux/drivers/infiniband/ulp/ipoib/ipoib.h
===
--- linux.orig/drivers/infiniband/ulp/ipoib/ipoib
On Fri, 9 Oct 2015, Anuj Kalia wrote:
> I am pretty excited about the CQE compression feature introduced in
> Mellanox OFED 3.1. Is this feature supported for ConnectX-3 or
> Connect-IB cards?
The other obvious question to ask is when can we expect this feature to be
upstream?
--
To unsubscribe
. The patch that implements the join is inline here:
Subject: ipoib multicast: Expire MC groups when the address expires
Upon address expiration do the proper thing to also expire the
sendonly multicast group.
Signed-off-by: Christoph Lameter <c...@linux.com>
Index: linux/drivers/infiniband/ulp
On Mon, 28 Sep 2015, Jason Gunthorpe wrote:
> Should we combine the user side of the kapi 'core' stack (libverbs,
> all open source providers, libumad, libcm) into one source
> package? Many projects have been working in that model lately with
> some success, IMHO.
Yes please.
> Right now we
On Mon, 28 Sep 2015, Doug Ledford wrote:
> No, I was referring to using this on top of your patch and my other two
> patches, which change the ipoib driver to create sendonly groups and
> then expire them when the neighbor expires.
Ok under which conditions could the joining be deferred and
On Mon, 28 Sep 2015, Doug Ledford wrote:
> > We would like to keep
> > irrelevant traffic off the fabric as much as possible. An a reception
> > event that requires traffic to be thrown out will cause jitter in the
> > processing of inbound traffic that we also would like to avoid.
>
> That may
On Mon, 28 Sep 2015, Doug Ledford wrote:
> On 09/28/2015 11:42 AM, Christoph Lameter wrote:
> > Where are these trees and who is maintaining them? I see that there is a
> > libibverbs on kernel.org that is updated by Doug.
> >
> > There are some mlx4/5 trees arou
On Mon, 28 Sep 2015, Or Gerlitz wrote:
> Personally, up to few weeks ago, I was under the misimpression that
> not only IPoIB joins as full member also on the sendonly flow, but
> also that such group can be actually opened under that flow, and it
> turns out they don't. Later you said that your
On Sat, 26 Sep 2015, Or Gerlitz wrote:
> It's possible that this was done for a reason, so
> sounds good, so taking into account that Erez is away till Oct 6th, we
> can probably pick your patch and later, if Erez proves us that there's
> deep problem there, revert it and take his.
Ok but if
On Sun, 27 Sep 2015, Doug Ledford wrote:
> Currently I'm testing your patch with a couple other patches. I dropped
> the patch of mine that added a module option, and added two different
> patches. However, I'm still waffling on this patch somewhat. In the
> discussions that Jason and I had, I
On Fri, 25 Sep 2015, Or Gerlitz wrote:
> On Thu, Sep 24, 2015 at 8:00 PM, Christoph Lameter <c...@linux.com> wrote:
> > Ok here is the fixed up and tested V2 of the patch. Can this go in with
> > Doug's patch?
>
>
> Repeating myself... do you find some over complex
And yes this went through testing here and we want to run this as part of
our prod kernels.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
on Erez work.
Signed-off-by: Christoph Lameter <c...@linux.com>
Index: linux/drivers/infiniband/ulp/ipoib/ipoib_main.c
===
--- linux.orig/drivers/infiniband/ulp/ipoib/ipoib_main.c2015-09-09
13:14:03.412350354 -0500
+++
On Wed, 16 Sep 2015, Doug Ledford wrote:
> > Abusing it for send-side is probably the wrong
> > direction overall.
>
> I wouldn't "abuse" it for such, I would suggest adding a proper notion
> of send-only registrations.
That is really not necessary for IP traffic. There is no need to track
these
On Wed, 16 Sep 2015, Doug Ledford wrote:
> On 09/15/2015 07:53 PM, Christoph Lameter wrote:
> > On Tue, 15 Sep 2015, Jason Gunthorpe wrote:
> >
> >> The mcast list in the core is soley for listing subscriptions for
> >> inbound - ie receive. Abusing it fo
Another approach may be to tie the unsub from sendonly multicast joins to
the expiration of the layer 2 addresses in IPoIB. F.e. add code to
__ipoib_reap_ah() to detect if the handle was used for a sendonly
multicast join. If so unsubscribe from the MC group. This will result in
behavior
On Wed, 16 Sep 2015, Or Gerlitz wrote:
> On Wed, Sep 16, 2015 at 7:31 PM, Christoph Lameter <c...@linux.com> wrote:
> > Another approach may be to tie the unsub from sendonly multicast joins to
> > the expiration of the layer 2 addresses in IPoIB. F.e. add code to
> >
On Wed, 16 Sep 2015, Or Gerlitz wrote:
> Could you please post here a few (say 2-4) liner summary of what is
> still missing or done wrong in 4.3-rc1 and what is your suggestion how
> to resolve that.
With Doug's patch here the only thing that is left to be done is to
properly leave the
On Tue, 15 Sep 2015, Jason Gunthorpe wrote:
> The mcast list in the core is soley for listing subscriptions for
> inbound - ie receive. Abusing it for send-side is probably the wrong
> direction overall.
Ok then a simple approach would be to port timeout logic from
OFED-1.5.X.
--
To unsubscribe
On Tue, 15 Sep 2015, Doug Ledford wrote:
>
> I actually think this is a step in the right direction, but I think we
> are talking about a layering violation doing it the way you are
> suggesting. What's more, there are a few difficulties here in that I'm
The function is used in various lower
On Fri, 11 Sep 2015, Doug Ledford wrote:
> > At a minimum, when the socket that did the send closes the send-only
> > could be de-refed..
>
> If we kept a ref count, but we don't. Tracking this is not a small change.
We could call ip_mc_join_group() from ipoib_mcast_send() which would join
it
On Thu, 10 Sep 2015, Doug Ledford wrote:
> + * 1) ifdown/ifup
> + * 2) a regular mcast join/leave happens and we run
> + *ipoib_mcast_restart_task
> + * 3) a REREGISTER event comes in from the SM
> + * 4) any other event that
We ran this through our tests and this works both for Infiniband and
Ethernet.
Tested-by: Christoph Lameter <c...@linux.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordo
On Fri, 21 Aug 2015, Jason Gunthorpe wrote:
> Even though we don't expect the group to be created by the SM we
> sill need to provide all the parameters to force the SM to validate
> they are correct.
Just ran into this issue with Redhat 7.1. Earlier code base. Same
problem. qkey etc not set.
On Wed, 5 Aug 2015, Amir Vadai wrote:
> This will be used by a revised version of the IP checksum patches [1], that
> will be sent later on.
Ok when can we get the full set for testing? Seems that the libibverbs and
libmlx4 portions are missing?
--
To unsubscribe from this list: send the line
Could you please post an updates patch that reflects the current state in
Matan's tree?
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Ok we tested this patchset with Matans timestamp-v2 branches from his repo
on github and the timestamps now work fine.
Can we please get the user space library bits into libibverbs and libmlx4?
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to
On Thu, 20 Aug 2015, Eran Ben Elisha wrote:
This patch-set adds a new implementation for multicast loopback prevention
for
mlx4 driver. The current implementation is very limited, especially if link
layer is Ethernet. The new implementation is based on HW feature of dropping
incoming
On Fri, 7 Aug 2015, Mike Marciniszyn wrote:
{
@@ -599,25 +581,21 @@ static ssize_t show_tempsense(struct device *device,
/* start of per-unit file structures and support code */
static DEVICE_ATTR(hw_rev, S_IRUGO, show_rev, NULL);
static DEVICE_ATTR(board_id, S_IRUGO, show_hfi, NULL);
On Wed, 8 Jul 2015, Christoph Hellwig wrote:
So how about someone tells OFED to stop trying to enforce this BS?
This just confirms my byass that Open-Fabrics Alliance are a bunch of
idiots making life hard, similar to all their horrible OFED driver
distributions that crated a total mess for
On Wed, 8 Jul 2015, Christoph Hellwig wrote:
On Wed, Jul 08, 2015 at 03:33:03PM -0400, Doug Ledford wrote:
I am not a lawyer, but this has been explained to me on numerous
occasions, so I relay the layman's interpretation here:
No, you don't always need everyone's approval. There are
On Fri, 31 Jul 2015, Marciniszyn, Mike wrote:
Please get someone knowledgeable at Intel to look at this. There is a (re=
v 04)
when using lspci on my nic here. This seems to be the hardware revision.
=20
I'm not sure what else to say other that the source for the sysfs file disp=
lay is
On Fri, 31 Jul 2015, Marciniszyn, Mike wrote:
+HFI1
+
+ The hfi1 driver also creates these additional files:
+
+ hw_rev - hardware revision
=20
I'm checking on this to see if it is indeed a duplicate.
=20
Our hardware architect has indicated there is not PCIe
On Fri, 31 Jul 2015, Doug Ledford wrote:
Everyone on that Cc: list (and I note in particular that your name is
*not* on that list) has been contacted and gave permission to
Avagotech/Emulex to go ahead and change the copyright on the code. As
such, it is their *right* to make that change
On Fri, 31 Jul 2015, Marciniszyn, Mike wrote:
And lspci as well as other tools will not be able to distinguish between
different versions of the hardware.
Sorry if I misled.
We do fully support the PCI revision number, and that will be set that diff=
erently for different hardware
On Fri, 31 Jul 2015, Jason Gunthorpe wrote:
If that wasn't done, the HW can't be changed, we are stuck with
wonky sysfs files.. Try and get it right next time shrug
And lspci as well as other tools will not be able to distinguish between
different versions of the hardware.
--
To unsubscribe
On Thu, 30 Jul 2015, Mike Marciniszyn wrote:
This patch adds the value of the CNP opcode to the existing list of enumerated
opcodes.
That is obvious and useless. Patches should have a meaningful
description and justify the changes.
Why do you add the CNP opcode and what in the world does it
On Thu, 30 Jul 2015, Marciniszyn, Mike wrote:
That is obvious and useless. Patches should have a meaningful description
and justify the changes.
The driver uses the CNP opcode for congestion control.
And that requires a new transport protocol???
Why do you add the CNP opcode and what
On Thu, 30 Jul 2015, Mike Marciniszyn wrote:
+HFI1
+
+ The hfi1 driver also creates these additional files:
+
+ hw_rev - hardware revision
+ board_id - manufacturing board id
+ version - driver version
+ tempsense - thermal sense information
+ serial - board serial number
+
On Thu, 30 Jul 2015, Mike Marciniszyn wrote:
As a verbs driver the device functions as an InfiniBand device and
supports the standard features of the IBTA specification v1.3 with
the exceptions noted below.
Hmmm... So OPA networks and IB networks (Truescale?) will be able to
interoperate?
On Wed, 15 Jul 2015, Christoph Hellwig wrote:
Many years ago we decided to move setting of IRQ to core affnities to
userspace with the irqbalance daemon.
These days we have systems with lots of MSI-X vector, and we have
hardware and subsystem support for per-CPU I/O queues in the block
On Wed, 8 Jul 2015, Marciniszyn, Mike wrote:
Are there any user space tools to control/exercise the driver and the
protocol stack?
There are diagnostic tools that are Intel specific that have device driver =
hooks.
Ok I hope these things are going to be merged at some point into the
ibnet
Is there any release schedule and/or upstream repo where I can see changes
for libibverbs and libmlx4?
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
We run those patches and we would like to see them upstream.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Ummm... This looks eerily similar to qib_verbs_mcast.c. Sed job on the
file? Is there any way to get a description as to what the differences are
between qib and hfi?
Can you just use the same file?
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message
Ummm.. Could we get some more descriptions as to what this code is for?
Do we have a new OmniPath protocol here as well or is it IB? Which
standards are followed?
I think the APIs that the driver uses need to be documented somewhere in
particular if new sysfs entries etc are created.
Are there
On Thu, 11 Jun 2015, Mike Marciniszyn wrote:
+static int query_device(struct ib_device *ibdev,
+ struct ib_device_attr *props)
+{
+ struct hfi1_devdata *dd = dd_from_ibdev(ibdev);
+ struct hfi1_ibdev *dev = to_idev(ibdev);
+
+ memset(props, 0,
On Wed, 10 Jun 2015, Hefty, Sean wrote:
There are multiple problems with libfrabric related to the use cases in m=
y
area. Most of all the lack of multicast support. Then there is the build
up of software bloat on top. The interest here is in low latency
operations. Redenzvous and other
On Mon, 8 Jun 2015, Hefty, Sean wrote:
You're assuming that the only start time of interest is when a send operati=
on has been posted. Jason asked what I would do with libfabric. That inte=
rface supports triggered operations. It has also been designed such that a=
rendezvous (that has
On Wed, 3 Jun 2015, Jason Gunthorpe wrote:
On Wed, Jun 03, 2015 at 07:55:58PM -0500, Christoph Lameter wrote:
I thknk the raw cycles and the rought oscillator speed are fine.
Time keeping is designed to adjust for 100's of ppm drift between
clocks.
What time keeping? Ntp? pptp is supposed
On Thu, 4 Jun 2015, Hefty, Sean wrote:
If I were adding timestamps, I would probably define a new completion
structure with 2 u64 time stamp fields (start and end times), and figure
out when start occurred, end occurred, and the timing metric later. :)
Not sure why you would need the start.
On Sat, 6 Jun 2015, Doug Ledford wrote:
The ppm rating is based upon the speed of the clock, not time. It's how
many cycles of variance you are allowed from the target speed given in
cycles / millions of cycles of the target clock frequency. If you have
a 312.5MHz clock, and your accuracy
On Mon, 1 Jun 2015, Hefty, Sean wrote:
We want to have a time stamp when the action is complete and the data is
available to the application or the send action is complete and the CQ
entry can be reused.
This is what polling the completion from the CQ tells you, independent of t=
here
On Wed, 3 Jun 2015, Jason Gunthorpe wrote:
MHz is fine *for mlx hardware* but someone elses hardware that uses,
say 312.5 MHz (ie the ethernet symbol clock) is NOT OK because MHz
looses too much precision.
Oscillator vary in frequency. In order to accurately convert to NS the
drift due to
1 - 100 of 244 matches
Mail list logo
