Hi Roland, I am using dmcli Python utility for SRP purposes. With x86_64, FedoraCore4, I get an error: Traceback (most recent call last): File /usr/local/ibg2/bin/dmcli, line 185, in ? main() File /usr/local/ibg2/bin/dmcli, line 149, in main agt = f.reg_agent(1) File
Roland,
This patch allows the consumer to set the page size of pages mapped
by the pool fmrs which is a feature already existing in the ib_verbs api.
On the cosmetic side it changes ib_fmr_attr.page_size field to be named
page_shift. Note that i did not go down to change mpt_entry-page_size
Hello Hal,
There is small bug in sminfo's cmdline processing, this will segfault
when option argument is missing (like 'sminfo -a'). The fast and dirty
fix is inlined.
The same problem exists with most diag tools, so I think we need to
rework AGRBEGIN { ... } ARGEND stuff (actually remove it
Quoting Or Gerlitz [EMAIL PROTECTED]:
A patch to convert the fmr consumers to the new api is below, if this
api change is accepted we will enhance iser code eg to fmr in 4K pages
resolution.
Out of curiosity, why would you want to make the page size smaller than
PAGE_SIZE? Bigger pages
Quoting Sasha Khapyorsky [EMAIL PROTECTED]:
Subject: [patch] userspace/management/diags/src/sminfo.c -cmdline processing
fix
Hello Hal,
There is small bug in sminfo's cmdline processing, this will segfault
when option argument is missing (like 'sminfo -a'). The fast and dirty
fix is
On 12:30 Tue 17 Jan , Michael S. Tsirkin wrote:
BTW, why arent the diags using the standard getopt_long?
That would solve the problem above in a clean way and help us get rid of
the ARGxxx macros completely.
Agree.
Sasha.
___
openib-general
Hi Michael,
I believe this is largely historical. I will put this on the list TODO for the
diags and hopefully get to it in the not too distant future.
-- Hal
From: Michael S. Tsirkin [mailto:[EMAIL PROTECTED]
Sent: Tue 1/17/2006 5:30 AM
To: Sasha Khapyorsky
Michael S. Tsirkin wrote:
Out of curiosity, why would you want to make the page size smaller than
PAGE_SIZE? Bigger pages typically give you better performance, isnt that true
for iser?
First just for the sake of clarity it is important to emphasize in the
verbs api level the decoupling of
Quoting Or Gerlitz [EMAIL PROTECTED]:
Second and indeed more important, from our experience, there are
eventually IB consumers such as the Linux SCSI Mid-Layer which sometimes
generate Scatter-Gather lists that are RDMA aligned when treated in a
resolution different from the system
Hi, I noticed that you checked in some ehca changes. A couple of comments:
1) While most of the changes to your #includes are correct, like
-#include hipz_fns_core.h
+#include hipz_fns_core.h
since you should use instead of for includes in your own local
directory to make the
Yael Are you planning to get this workaround in dmcli?
Not really -- I think the C version of the DM client that I posted
later is more useful. By the way, I still need to integrate Alexander
Beyn's fix to that code, and I will do that soon.
Even better would be if someone ambitious created
Hello Roland,
thanks for your comments. We will include
the changes it in our code and do then a new OpenIB SVN check-in.
Mit freundlichen Gruessen / Kind Regards
Heiko Joerg Schick
IBM Deutschland Entwicklung GmbH
I/O Firmware Development II
Linux Infiniband Device Drivers
Schoenaicher Str.
Hi Sasha,
Thanks. Applied.
I would welcome such a patch.
-- Hal
From: Sasha Khapyorsky [mailto:[EMAIL PROTECTED]
Sent: Tue 1/17/2006 5:10 AM
To: Hal Rosenstock
Cc: openib
Subject: [patch] userspace/management/diags/src/sminfo.c - cmdline processing
fix
Hi,
I was updating my kernel and openib drivers (haven't done so for a
couple of months) and I've got stuck on the following problem.
When you do make modules_install you can the following warnings at the end:
WARNING: /lib/modules/2.6.15.1/kernel/drivers/infiniband/ulp/sdp/ib_sdp.ko
needs
Arlin,
a few things need to be addressed.
1. correlation with local and remote
invalidate
This potentially effects both DAT_DTOs and post
operations
2. Need a precise defintion for CONFIRM_FLAG definition
in a transport independent fashion.
What guarantees DAT Provider "provides" on
I notice this was fixed for 2.6.14 with a patch that exported the
ip_dev_find symbol. Do we need one for 2.6.15.1 or have I missed a
step out of my installation process?
The same fix is necessary. You can apply the 2.6.14 patch to 2.6.15.1.
___
Arlin,
1. Does it mean that existing DAT providers will have
to be modified so they report
DAT_NOT_IMPLEMENTED for each
extension?
2. Why is there DAT_INVALID in
DAT_DTOS?
3. Do you want to use DAT_EXTENSION_DATA or
DAT_EXT_DATA?
4. The proposed operations are operation on EP and they
Hi,
I am trying to write a test that will send/receive packets directly
above IBUMAD.
Does anyone have such a chunk of code that do this?
Thanks a lot in advance!
Ofer
___
openib-general mailing list
openib-general@openib.org
Hi Ofer,
Are you referring to the kernelmodule or the library here ?
-- Hal
From: [EMAIL PROTECTED] on behalf of Ofer Gigi
Sent: Tue 1/17/2006 11:19 AM
To: openib-general@openib.org
Subject: [openib-general] Send packets above ibumad and waiting for
At long last I've integrated your patch into srptools. I took this as
an excuse to check the DM package into svn under
https://openib.org/svn/gen2/trunk/src/userspace/srptools
as well, rather than passing tarballs around on the mailing list.
Thanks,
Roland
Roland wrote,
However my reasoning could easily be all wrong -- what are the
advantages of having it in openib svn?
- R.
I guess one could go either way. The benefit of keeping it
in SVN is that it that if any changes are needed, they are
in some database until they are pushed upstream. The
Hi Ralph,
This is much simpler :-)
Thanks! Applied.
I tested this both in an operational network with some different topologies as
well as passing the previously failed compliance C14-11.
-- Hal
From: [EMAIL PROTECTED] on behalf of Ralph Campbell
Sent:
On 1/17/06, Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Quoting Or Gerlitz [EMAIL PROTECTED]:
Second and indeed more important, from our experience, there are
eventually IB consumers such as the Linux SCSI Mid-Layer which sometimes
generate Scatter-Gather lists that are RDMA aligned when
Thanks, applied.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Thanks, applied.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
-while (!skb_queue_empty(mcast-pkt_queue))
+while (!skb_queue_empty(mcast-pkt_queue)) {
+spin_lock_irqsave(priv-tx_lock, flags);
+++priv-stats.tx_dropped;
+spin_unlock_irqrestore(priv-tx_lock, flags);
Thanks, applied.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [PATCH] ipoib: pkt_queue
- while (!skb_queue_empty(mcast-pkt_queue))
+ while (!skb_queue_empty(mcast-pkt_queue)) {
+ spin_lock_irqsave(priv-tx_lock, flags);
+ ++priv-stats.tx_dropped;
+
Michael We seem to be doing operations that cant be called under
Michael tx_lock a few lines below.
Do you mean dev_queue_xmit()? Can that call directly back into our
xmit function (I honestly don't know the locking rules here)?
- R.
___
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Subject: [openib-general] Re: [PATCH] ipoib: pkt_queue
Michael We seem to be doing operations that cant be called under
Michael tx_lock a few lines below.
Do you mean dev_queue_xmit()? Can that call directly back into our
xmit function
Quoting r. Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: Re: [PATCH] ipoib: pkt_queue
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Subject: [openib-general] Re: [PATCH] ipoib: pkt_queue
Michael We seem to be doing operations that cant be called under
Michael tx_lock a few
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Any reason to drop the lock every time around this loop? Would it
make more sense to count the number of packets and then just add it in
after the loop?
Is this better?
--
Protect accesses to mcast-pkt_queue by tx_lock.
Count multicast packets
Quoting r. Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: Re: ipoib: outstanding patches
Quoting Roland Dreier [EMAIL PROTECTED]:
ipoib_mcast_send.patch
Could we reuse the IPOIB_MCAST_RUN bit rather than adding a new bit?
It seems that we could kill mcast_mutex and replace uses
Kanevsky, Arkady wrote:
Arlin,
1. Does it mean that existing DAT providers will have to be modified
so they report
DAT_NOT_IMPLEMENTED for each extension?
No.
During the open, a dat library built to support extensions, a query call
is made to verify that the provider supports extensions
Hi, Michael -
I have found some code in the OpenIB Subversion repo that appears to
have been committed by you, and which has Mellanox proprietary licenses
in the header files.
Most of the files in the src/userspace/imgen directory contain the
following boilerplate text:
*
Arlin Davis wrote:
Kanevsky, Arkady wrote:
5. Memory protection extension for atomic operations
6. error returns for extensions?
yes and yes; I will work these into the next patch and update the
proposal.
For error returns I am thinking about carving up the return type, adding
a
Does this actually work?
+if (!test_bit(IPOIB_MCAST_RUN, priv-flags) || !priv-broadcast) {
+dev_kfree_skb_any(skb);
+goto unlock;
+}
It seems that this code at the end of ipoib_mcast_join_task() might
screw things up:
ipoib_dbg_mcast(priv,
Yes, looks good ... committed
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Seems reasonable. Unfortunately we just missed the 2.6.16-rc1 window
so I think this should wait for the 2.6.17 window.
BTW, do you ever see the SCSI layer giving you 512 byte blocks?
- R.
___
openib-general mailing list
openib-general@openib.org
Quoting Roland Dreier [EMAIL PROTECTED]:
It seems that this code at the end of ipoib_mcast_join_task() might
screw things up:
ipoib_dbg_mcast(priv, successfully joined all multicast groups\n);
clear_bit(IPOIB_MCAST_RUN, priv-flags);
Right. That probably was the reason I
Michael Kind of like what original patch in svn does?
Yeah -- my original question about reusing the MCAST_RUN bit was an
honest question -- and it seems the answer is probably, no, we need
another bit to make it work.
It seems that killing mcast_mutex might be a good, independent cleanup.
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [openib-general] Re: ipoib_mcast_send.patch
Michael Kind of like what original patch in svn does?
Yeah -- my original question about reusing the MCAST_RUN bit was an
honest question -- and it seems the answer is probably, no, we
This patch fixes a minor misspelling in SDP.
Signed-off-by: Ralph Campbell [EMAIL PROTECTED]
Index: ulp/sdp/sdp_inet.c
===
--- ulp/sdp/sdp_inet.c (revision 5055)
+++ ulp/sdp/sdp_inet.c (working copy)
@@ -836,7 +836,7 @@
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: [PATCH 1 of 3] move destructor to struct neigh_parms
This is an alternative approach to the one presented in
ipoib_all_neigh_issues_2.patch.
---
Move destructor from neigh_ops (which is shared between devices)
to neigh_parms which
The following set of patches defines a connection abstraction for Infiniband and
other RDMA devices, and serves several purposes:
* It implements a connection protocol over Infiniband based on IP addressing.
This greatly simplifies clients wishing to establish connections over
Infiniband.
* It
The following patch provides common handling for marshalling data between
userspace clients and kernel mode Infiniband drivers.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/Makefile
The following patch extends matching connection requests to listens in the
Infiniband CM to include private data.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/cm.c
The following provides an address translation service that maps IP addresses
to Infiniband addresses (GIDs) using IPoIB.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/addr.c
The following patch implements a kernel mode connection management agent
over Infiniband that connects based on IP addresses.
The agent defines a generic RDMA connection abstraction to support clients
wanting to connect over different RDMA devices.
It also handles RDMA device hotplug events on
Minor nits.
On Tue, 17 Jan 2006 15:24:37 -0800
Sean Hefty [EMAIL PROTECTED] wrote:
The following patch extends matching connection requests to listens in the
Infiniband CM to include private data.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
+static void cm_mask_compare_data(u8
This patch adds the kernel component to support the userspace Infiniband/RDMA
connection agent library.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/Makefile
+static void cm_mask_compare_data(u8 *dst, u8 *src, u8 *mask)
static void cm_mask_compare_data(u8 *dst, const u8 *src, u8 *mask)
but I would rename it to cm_mask_copy since it doesn't really do a compare.
I'll change this. The function is masking the data to use in the comparison,
but I can
On Tue, Jan 17, 2006 at 03:24:37PM -0800, Sean Hefty wrote:
+static void cm_mask_compare_data(u8 *dst, u8 *src, u8 *mask)
+{
+ int i;
+
+ for (i = 0; i IB_CM_PRIVATE_DATA_COMPARE_SIZE; i++)
+ dst[i] = src[i] mask[i];
+}
Is this code going to get invoked very often?
flamebait
Also should infiniband exports be EXPORT_SYMBOL_GPL, to make
it clear that binary drivers for this are not allowed??
/flamebait
the dual license text needs a bit of clarification I suspect to make
explicit that the or BSD part only applies when used entirely outside
the linux
54 matches
Mail list logo
