Hello,
We tried contacting you awhile ago about your low interest morta(ge rate.
You have qualified for the lowest rate in years...
You could get over $380,000 for as little as $500 a month!
Ba(d credit? Doesn't matter, low rates are fixed no matter what!
To get a free, no obli,gation c
At 09:56 AM 3/3/2005, Talpey, Thomas wrote:
>that. At present, the code is heavily commented and fully generalized to
>aid porting to multiple operating systems. It will look quite different once
>it is freed of these attributes. Also, I'll point out there is extensive debug
>and trace throughout t
Libor> When you say locking mess, do you mean accessing and
Libor> potentially deleting the object which is referenced by the
Libor> IDR table outside of the lock used to access the IDR?
I just meant the fact that right now I have to hold the idr mutex over
both looking up an old obj
On Thu, Mar 03, 2005 at 06:02:20PM -0800, Roland Dreier wrote:
> Libor> I was thinking of maybe ref counting the access, either in
> Libor> ib_qp or ib_uobject. Adding a pair of functions, lookup and
> Libor> return, to manage the ref count...
>
> I think it makes sense to put a ref c
Libor> I was thinking of maybe ref counting the access, either in
Libor> ib_qp or ib_uobject. Adding a pair of functions, lookup and
Libor> return, to manage the ref count...
I think it makes sense to put a ref count in struct ib_uobject. That
would make it easier to enforce things l
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > Roland Dreier <[EMAIL PROTECTED]> wrote:
> > >
> > > >> don't add casts to a void pointer, that's silly.
> > >
> > > How should we handle this nit? Should I post a new version of this
> > > patch or
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> Roland Dreier <[EMAIL PROTECTED]> wrote:
> >
> > >> don't add casts to a void pointer, that's silly.
> >
> > How should we handle this nit? Should I post a new version of this
> > patch or an incremental diff that fixes it up?
> >
>
> I'll fix it
Greg> Sure, I have no problem accepting that into the pci core.
What would pci_irq_sync() do exactly?
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit htt
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> >> don't add casts to a void pointer, that's silly.
>
> How should we handle this nit? Should I post a new version of this
> patch or an incremental diff that fixes it up?
>
I'll fix it up.
___
openib-g
>I thought about that, here's the current list, but we would need to
>lookup the pd anyway:
>
>qp->pd,
>qp->qp_num
>qp->qp_type
>qp->srq
>qp->device
The kernel CM uses the PD of an internal mad_agent, and not the PD of the
user's QP. So, I don't think it's
On Thu, Mar 03, 2005 at 07:35:00PM -0500, Jeff Garzik wrote:
> Roland Dreier wrote:
> >@@ -783,6 +777,11 @@
> > cq->cqn & (dev->limits.num_cqs - 1));
> > spin_unlock_irq(&dev->cq_table.lock);
> >
> >+if (dev->mthca_flags & MTHCA_FLAG_MSI_X)
> >+ synchronize_irq(de
On Thu, Mar 03, 2005 at 04:37:45PM -0800, Roland Dreier wrote:
> Libor> Roland, As it currently stands, the userspace CM needs to
> Libor> pass a QP from userspace to kernel space in order to pass
> Libor> it on to the kernel CM. I'm thinking that the best way to
> Libor> handle th
Jeff> Well, we don't just add code to "hope and pray" for an event
Jeff> that nobody is sure can even occur...
The hardware requires that if the record is written in two 32-bit
chunks, then they must be written in order. Of course the hardware
probably won't be reading just as we're writi
>> don't add casts to a void pointer, that's silly.
How should we handle this nit? Should I post a new version of this
patch or an incremental diff that fixes it up?
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/
Roland Dreier wrote:
Jeff> Are you concerned about ordering, or write-combining?
ordering... write combining would be fine.
Jeff> I am unaware of a situation where writes are re-ordered into
Jeff> a reversed, descending order for no apparent reason.
Hmm... I've seen ppc64 do some pretty
> @@ -783,6 +777,11 @@
> cq->cqn & (dev->limits.num_cqs - 1));
> spin_unlock_irq(&dev->cq_table.lock);
> +if (dev->mthca_flags & MTHCA_FLAG_MSI_X)
> + synchronize_irq(dev->eq_table.eq[MTHCA_EQ_COMP].msi_x_vector);
> + else
> + synchroni
> As it currently stands, the userspace CM needs to pass a QP from
>userspace to kernel space in order to pass it on to the kernel CM.
>I'm thinking that the best way to handle this is for the uCM library
>to pass uCM kernel the uverbs QP handle, and then have the kernel
>uCM lookup the QP from ib
Libor> Roland, As it currently stands, the userspace CM needs to
Libor> pass a QP from userspace to kernel space in order to pass
Libor> it on to the kernel CM. I'm thinking that the best way to
Libor> handle this is for the uCM library to pass uCM kernel the
Libor> uverbs QP h
Roland Dreier wrote:
@@ -783,6 +777,11 @@
cq->cqn & (dev->limits.num_cqs - 1));
spin_unlock_irq(&dev->cq_table.lock);
+ if (dev->mthca_flags & MTHCA_FLAG_MSI_X)
+ synchronize_irq(dev->eq_table.eq[MTHCA_EQ_COMP].msi_x_vector);
+ else
+ synchronize_irq(dev->pdev->irq);
+
Tangent: I thin
>Roland Dreier wrote:
>> +void cancel_sends(void *data)
>> +{
>> +struct ib_mad_agent_private *mad_agent_priv;
>> +struct ib_mad_send_wr_private *mad_send_wr;
>> +struct ib_mad_send_wc mad_send_wc;
>> +unsigned long flags;
>> +
>> +mad_agent_priv = (struct ib_mad_agent_private *
Jeff> Are you concerned about ordering, or write-combining?
ordering... write combining would be fine.
Jeff> I am unaware of a situation where writes are re-ordered into
Jeff> a reversed, descending order for no apparent reason.
Hmm... I've seen ppc64 do some pretty freaky reordering
Jeff> don't add casts to a void pointer, that's silly.
Fair enough...
Jeff> dumb question... why is the lock dropped? is it just for
Jeff> the send_handler(), or also for wr_id assigned, kfree, and
Jeff> wake_up() ?
Not sure... Sean?
- R.
__
Roland,
As it currently stands, the userspace CM needs to pass a QP from
userspace to kernel space in order to pass it on to the kernel CM.
I'm thinking that the best way to handle this is for the uCM library
to pass uCM kernel the uverbs QP handle, and then have the kernel
uCM lookup the QP fro
Roland Dreier wrote:
+void cancel_sends(void *data)
+{
+ struct ib_mad_agent_private *mad_agent_priv;
+ struct ib_mad_send_wr_private *mad_send_wr;
+ struct ib_mad_send_wc mad_send_wc;
+ unsigned long flags;
+
+ mad_agent_priv = (struct ib_mad_agent_private *)data;
don
Roland Dreier wrote:
Add a mthca_write_db_rec() to wrap writing doorbell records. On
64-bit archs, this is just a 64-bit write, while on 32-bit archs it
splits the write into two 32-bit writes with a memory barrier to make
sure the two halves of the record are written in the correct order.
+stati
From: Sean Hefty <[EMAIL PROTECTED]>
Modify ib_cancel_mad() to invoke a user's send completion callback from
a different thread context than that used by the caller. This allows a
caller to hold a lock while calling cancel that is also acquired from
their send handler.
Signed-off-by: Sean Hefty
Tie up one last loose end by mapping enough context memory to cover
the whole multicast table during initialization, and then enable
mem-free mode. mthca now supports enough of mem-free mode so that
IPoIB works with a mem-free HCA.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-expo
From: Michael S. Tsirkin <[EMAIL PROTECTED]>
Set device_cap_flags field in mthca's query_device method.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/hw/mthca/mthca_cmd.h 2005-01-25
20:48:02.000
Implement posting send and receive work requests for mem-free mode.
Also tidy up a few things in send/receive posting for Tavor mode (fix
smp_wmb()s that should really be just wmb()s, annotate tests in the
fast path with likely()/unlikely()).
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
From: Michael S. Tsirkin <[EMAIL PROTECTED]>
1. Split the QP spinlock into separate send and receive locks.
The only place where we have to lock both is upon modify_qp, and
that is not on data path.
2. Avoid taking any QP locks when polling CQ.
This last part is achieved by getting rid
Update QP initialization and cleanup to handle mem-free mode. In
mem-free mode, work queue sizes have to be rounded up to a power of 2,
we need to allocate doorbells, there must be memory mapped for the
entries in the QP and extended QP context table that we use, and the
entries of the receive que
Update address vector handling to support mem-free mode. In mem-free
mode, the address vector (in hardware format) is copied by the driver
into each send work queue entry, so our address handle creation can
become pretty trivial: we just kmalloc() a buffer to hold the
formatted address vector.
Si
Add support for CQ data path operations (request notification, update
consumer index) in mem-free mode.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/hw/mthca/mthca_cq.c2005-03-03
14:13:00.312829664 -0800
+++ linux-export/drivers/infiniband/hw/mth
Update CQ initialization and cleanup to handle mem-free mode: we need
to make sure the HCA has memory mapped for the entry in the CQ context
table we will use and also allocate doorbell records.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/hw/mthca/mt
Add a mthca_write_db_rec() to wrap writing doorbell records. On
64-bit archs, this is just a 64-bit write, while on 32-bit archs it
splits the write into two 32-bit writes with a memory barrier to make
sure the two halves of the record are written in the correct order.
Signed-off-by: Roland Dreie
Factor the allocation and freeing of completion queue buffers into
mthca_alloc_cq_buf() and mthca_free_cq_buf(). This makes the code
more readable and will eventually make handling userspace CQs simpler
(the kernel doesn't have to allocate a buffer at all).
Signed-off-by: Roland Dreier <[EMAIL PR
Mem-free mode requires the driver to allocate additional doorbell pages
for each user access region. Add support for this in mthca_memfree.c,
and have the driver allocate a table in db_tab for kernel use.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/
Have MAP_ICM_page() firmware command map assume pages are always the
HCA-native 4K size rather than using the kernel's page size. This
will make handling doorbell pages for mem-free mode simpler.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/hw/mthca/
Slightly improve debugging output for UNMAP_ICM and MODIFY_QP firmware commands.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/hw/mthca/mthca_cmd.c 2005-01-25
20:48:02.0 -0800
+++ linux-export/drivers/infiniband/hw/mthca/mthca_cmd.c2
Update interrupt handling code to handle mem-free mode. While we're
at it, improve the Tavor interrupt handling to avoid an extra MMIO
read of the event cause register.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/hw/mthca/mthca_dev.h 2005-03-03
1
Add code to initialize EQ context properly in both Tavor and mem-free mode.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/hw/mthca/mthca_eq.c2005-03-03
14:12:56.154732247 -0800
+++ linux-export/drivers/infiniband/hw/mthca/mthca_eq.c 2005-03-03
14
Add support for mem-free mode to memory region code. This mostly
amounts to properly munging between keys and indices.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/hw/mthca/mthca_mr.c2005-01-15
15:16:11.0 -0800
+++ linux-export/drivers/i
Add support for allocating user access regions (UARs). Use this to
allocate a region for kernel at driver init instead using hard-coded
MTHCA_KAR_PAGE index.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/hw/mthca/Makefile 2005-01-15
15:16:40.000
Add support for mapping more memory into HCA's context to cover
context tables when new objects are allocated. Pass the object
size into mthca_alloc_icm_table(), reference count the ICM chunks,
and add new mthca_table_get() and mthca_table_put() functions to
handle mapping memory when allocating o
Move the request/ioremap of regions related to event handling into
mthca_eq.c. Map the correct regions depending on whether we're in
Tavor or native mem-free mode.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/hw/mthca/mthca_config_reg.h
2005-01-2
From: Michael S. Tsirkin <[EMAIL PROTECTED]>
Remove support for unsignaled receive requests. This is a
non-standard extension to the IB spec that is not used by any known
applications or protocols, and is not supported by newer hardware.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Sign
Simplify some of the code for CQ handling slightly.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/hw/mthca/mthca_cq.c2005-03-03
14:12:52.923433653 -0800
+++ linux-export/drivers/infiniband/hw/mthca/mthca_cq.c 2005-03-03
14:12:53.538300187 -0800
@
From: Michael S. Tsirkin <[EMAIL PROTECTED]>
Locking during the poll cq operation can be reduced by locking the cq
while qp is being removed from the qp array. This also avoids an
extra atomic operation for reference counting.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Signed-off-by:
From: Michael S. Tsirkin <[EMAIL PROTECTED]>
Avoid taking the CQ table lock in the fast path path by using
synchronize_irq() after removing a CQ from the table to make sure that
no completion events are still in progress. This gets a nice speedup
(about 4%) in IP over IB on my hardware.
Signed-o
From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
Clean up CQ code so that we only calculate the address of a CQ entry
once when using it.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/hw/mthca/mthca_
From: Sean Hefty <[EMAIL PROTECTED]>
Fix ib_find_cached_gid() to return the correct port number relative to
the port numbering used by the device.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/core/cache.c
Here's another series of patches that applies on top of the fixes I
posted yesterday. This series syncs the kernel with everything ready
for merging from the OpenIB subversion tree.
Most of these patches add more support for "mem-free" mode to mthca.
This allows PCI Express HCAs to operate by sto
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] mr_table.max_mtt_order
>
> Roland> I thought about this a little. I think that any inline
> Roland> function forces someone reading the code to look up what
> Roland> it does, no matter how descriptive the
Roland> I thought about this a little. I think that any inline
Roland> function forces someone reading the code to look up what
Roland> it does, no matter how descriptive the name we come up
Roland> with. I think it would be better to use fls() directly.
Roland> I'm already in
> -Original Message-
> From: Christoph Hellwig [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 03, 2005 5:48 AM
> To: Yaron Haviv
> Cc: Christoph Hellwig; James Lentini; openib-general@openib.org
> Subject: Re: [openib-general] putting in dead wood for DAPL and
> similarabomination
>
> T
Thanks for the kind words Tom.
Indeed, Ammasso is fully open source and are thrilled at the
idea of getting DAPL into the mainline. We went GA with our 1.2 release
recently and have had our AMSO100 hardware and associated iWARP software
in the hands of about 60 different sites - both HPTC and com
At 10:48 PM 3/2/2005, Christoph Hellwig wrote:
>The current iSER code is 10928 LOC, add to that 22155 LOC of kDAPL (not
>including the actual provider for IB) and 5822 LOC linux-iscsi kernel
>code. Compare that to the 25412 LOC total for drivers/infiniband in Linux
>2.6.11.
Is this just about LOCs
At 02:22 PM 3/2/2005, Woodruff, Robert J wrote:
>I think the point is that only one of those interconnects (IB) is
>in the kernel, the rest are proprietary. Do any of the other RDMA
>interconnect vendors plan to submit their code for inclusion into Linux
>in the near future ?
Yes - take a look a
>
> The advantage of ATS is that it "just works" whether wired point to
> point, or via a switch, or whatever. It requires no central
> administration,
> works as transparently as ARP and ND, and supports IP addressing so
> applications don't have any ambiguity in how they resolve names.
>
> If
59 matches
Mail list logo
