On Tue, Aug 10, 2010 at 8:34 PM, Bart Van Assche bvanass...@acm.org wrote:
The SRP (draft) standard specifies that an SRP initiator must never queue more
Note: this patch still has the old (incorrect) patch description. Will
post a patch with an updated description soon.
Bart.
--
To unsubscribe
As proposed by the SRP (draft) standard, ib_srp reserves one ring element for
SRP_TSK_MGMT requests. This patch makes sure that the SCSI mid-layer never
tries to queue more than (SRP request limit) - 1 SCSI commands to ib_srp. This
improves performance for targets whose request limit is less than
Bob Pearson wrote:
My interest is supporting the rxe driver, a software implementation of
the IB transport over Ethernet, [...] I spent a little time looking at
trying to exploit congestion notification to see if it would bu useful in
this context.
Hi Bob,
As the IB congestion control /
I never got a response to our last discussions of this issue; to remind
everyone, this is a patch for handling BUSY responses from the SA in the same
manner time outs are handled. The purpose of this change is to prevent poorly
written applications from overloading the SM, or failing when they
In addition to the patch itself, there has been significant discussion
about changing the APIs to allow the application to explicitly specify how
to handle BUSY.
The current code allows an app to explicitly handle BUSY replies, so we don't
need changes for that. I was advocating making
The problem is that none of the apps **do** handle BUSY - at all - and your
proposal still requires the apps to be changed to stop them from degrading the
fabric.
The whole benefit of this change is that it implements a reasonable default
without requiring the apps be changed, but still allows
The problem is that none of the apps **do** handle BUSY - at all - and your
proposal still requires the apps to be changed to stop them from degrading
the fabric.
Yes - the apps are busted, so I do believe that the fixes are required there
and not in the kernel. If you want to fix them by
From: Hefty, Sean [mailto:sean.he...@intel.com]
The problem is that none of the apps **do** handle BUSY - at all -
and your
proposal still requires the apps to be changed to stop them from
degrading
the fabric.
Yes - the apps are busted, so I do believe that the fixes are required
Coding IB applications is hard enough, let's not require it to be harder.
We need a solution that fixes all the apps and makes it easy for future
applications to have a sensible default behavior.
The mad interface is privileged, not some generic API available to any user
space app.
I think
It breaks the ABI and existing apps that *do* handle BUSY replies. We can't
assume that no apps out there aren't written correctly.
I could be wrong, but I couldn't find a single example in the OFED 1.5.2
package.
-Original Message-
From: Hefty, Sean [mailto:sean.he...@intel.com]
Sean,
What if we reversed the sense of your idea - if the app or ulp provides a
positive timeout number, apply the combined time-out concept, but if it
provides a negative number, force it to handle BUSY itself? This would provide
a good quality default behavior.
Also - it still makes sense
From: Hefty, Sean [mailto:sean.he...@intel.com]
It breaks the ABI and existing apps that *do* handle BUSY replies. We
can't assume that no apps out there aren't written correctly.
The mad interface is privileged, not some generic API available to any
user space app.
I have yet to find
It seems the new API has too many constraints for XRC. There are a couple
things that don't fit:
- XRC needs a domain, which must be created before creating the QP, but
after we know
the device to use. In addition it also needs a file descriptor. The
application may
want to use a
On 08/11/2010 05:22 PM, Hefty, Sean wrote:
- The server side of the connection also needs an SRQ. It's not
obvious whether it's the application or rdma cm to create that SRQ.
And that SRQ number must be given to the client side, presumably in
the private data.
The desired mapping of XRC to
On Wed, Aug 11, 2010 at 03:22:45PM -0700, Hefty, Sean wrote:
It seems the new API has too many constraints for XRC. There are a couple
things that don't fit:
- XRC needs a domain, which must be created before creating the QP, but
after we know
the device to use. In addition it also
Maybe 3 functions, since you already have create_ep:
create_id_ep - takes rdma_addrinfo, allocates PD/XRC, rdma_cm_id
create_qp_ep - takes rdma_addrinfo, allocates QP, CQ, etc
create_ep - just calls both the above. Very simplified
(not sure on the names)
This is similar to what I was
On Wed, Aug 11, 2010 at 05:04:00PM -0700, Hefty, Sean wrote:
Maybe 3 functions, since you already have create_ep:
create_id_ep - takes rdma_addrinfo, allocates PD/XRC, rdma_cm_id
create_qp_ep - takes rdma_addrinfo, allocates QP, CQ, etc
create_ep - just calls both the above. Very
Even so, the point of passing it into rdma_getaddrinfo is to restrict
the device rdma_getaddrinfo selects, it doesn't matter that you can get
back to the PD from the addrinfo if that PD doesn't have the resources
you need attached to it. Again, I'm thinking from the app perspective
where
On Wed, Aug 11, 2010 at 08:30:53PM -0700, Hefty, Sean wrote:
Even so, the point of passing it into rdma_getaddrinfo is to restrict
the device rdma_getaddrinfo selects, it doesn't matter that you can get
back to the PD from the addrinfo if that PD doesn't have the resources
you need
19 matches
Mail list logo
