On Tue, Oct 12, 2010 at 06:29:53PM +0200, Alekseys Senin wrote:
On Tue, 2010-10-05 at 14:12 -0500, Christoph Lameter wrote:
On Tue, 5 Oct 2010, Jason Gunthorpe wrote:
On Tue, Oct 05, 2010 at 06:07:37PM +0200, Aleksey Senin wrote:
When using slow SM allow more packets to be
On Wed, 6 Oct 2010, Alekseys Senin wrote:
How do you handle the situation of the SM responding before the fabric has
been reconfigured? I do not see any delay on join. So they will be dropped
if the fabric was not reconfigured fast enough? Or does the SM somehow
delay the response?
I
On Wed, Oct 06, 2010 at 11:16:59AM -0500, Christoph Lameter wrote:
Relating to broadcast, I don't think that this is a good solution it
will bring unwarranted load, specially in the case if no MLID received.
The way of adding delay before we start to send packages, seems to me
better.
When using slow SM allow more packets to be buffered before answer
comming back. This patch based on idea of Christoph Lameter.
http://lists.openfabrics.org/pipermail/general/2009-June/059853.html
Signed-off-by: Aleksey Senin aleks...@voltaire.com
---
drivers/infiniband/ulp/ipoib/ipoib.h
On Tue, Oct 05, 2010 at 06:07:37PM +0200, Aleksey Senin wrote:
When using slow SM allow more packets to be buffered before answer
comming back. This patch based on idea of Christoph Lameter.
http://lists.openfabrics.org/pipermail/general/2009-June/059853.html
IMHO, I think it is better to
On Tue, 5 Oct 2010, Jason Gunthorpe wrote:
On Tue, Oct 05, 2010 at 06:07:37PM +0200, Aleksey Senin wrote:
When using slow SM allow more packets to be buffered before answer
comming back. This patch based on idea of Christoph Lameter.
On Tue, 5 Oct 2010, Aleksey Senin wrote:
When using slow SM allow more packets to be buffered before answer
comming back. This patch based on idea of Christoph Lameter.
I agree, I think we need to have those things configurable.
Reviewed-by: Christoph Lameter c...@linux.com
How do you handle
On Tue, Oct 05, 2010 at 02:12:57PM -0500, Christoph Lameter wrote:
On Tue, 5 Oct 2010, Jason Gunthorpe wrote:
On Tue, Oct 05, 2010 at 06:07:37PM +0200, Aleksey Senin wrote:
When using slow SM allow more packets to be buffered before answer
comming back. This patch based on idea of
On Tue, 5 Oct 2010, Jason Gunthorpe wrote:
I agree. We had similar ideas. However, the kernel does send igmp
reports to the MC address not to 244.0.0.2. We would have to redirect at
the IB layer until multicast via MLID becomes functional. We cannot tell
when that will be the case.
On Tue, 5 Oct 2010, Jason Gunthorpe wrote:
How do you propose to handle the IB level join to 224.0.0.22 to avoid
packet loss there? IGMP messages will still get lost because of that.
First, the routers all join the group at startup and stay joined
forever. This avoids the race in the route
On Tue, 5 Oct 2010, Jason Gunthorpe wrote:
The problem is that the client join on 224.0.0.22 will be delayed due to
fabric reconfig. The group is joined on demand. It is not automatically
joined.
I was trying to explain that it is possible for the SM to provide a
MLID that is fully
11 matches
Mail list logo
