Bob Pearson wrote:
I was wondering if I could use this to cause ConnectX RDMAoE senders to slow down
in response to these packets. There is a challenge managing fast ROCE senders
in networks that may not fully implement per priority pause.
Hi Bob,
QCN (IEEE 802.1 based Ethernet congestion c
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
> 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 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 si
> 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 thi
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 additi
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
> 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
> 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
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 to
> 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]
> 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 thi
> 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
> 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
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
> 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 thi
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 r
When option is enabled, same mlid may be assigned to
multicast groups created by IPoIB IPv4.
32-bit mask can be defined in configuration file
using option mcast_ipv4_mux_mask.
If there is no difference in 32 lsb bits of MGID,
multicast group will got same mlid.
Signed-off-by: Slava Strebkov
---
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 /
19 matches
Mail list logo
