Thanks for the comments
>> To fix it, this patch adds a dev field to struct ipoib_neigh which is used
>> instead of the struct neighbour dev one.
>
> It seems that in this design, if multiple ipoib interfaces are present, we
> might
> get an skb such that skb->dev will be different from the ne
Hi,
This post follows a previous one, regarding required changes to IPoIB to enable
it to work with bonding. Please find it here:
http://openib.org/pipermail/openib-general/2007-February/032598.html
This patch version adds fixes to the comments from Michael Tsirkin from the
last post.
IPoIB us
Michael S. Tsirkin wrote:
>> Quoting Moni Shoua <[EMAIL PROTECTED]>:
>> Subject: Re: [PATCH] IB/ipoib get net_device from ipoib_neigh instead of
>> linux neighbour
>>
>>
>>> Another concern: assume that one device goes away (e.g. hotplug).
>>
> Another concern: assume that one device goes away (e.g. hotplug).
> It seems that neighbours whose dev field point to another device, will not be
> destroyed.
> Correct?
I agree.
>
> Therefore in your design, it seems that to_ipoib_neigh()->dev
> will get us a pointer to device that has been r
Michael S. Tsirkin wrote:
>>--
>>IPoIB uses a two layer neighboring scheme, such that for each struct neighbour
>>whose device is an ipoib one, there is a struct ipoib_neigh buddy which is
>>created on demand at the tx flow
igh_destructor) assumes that for each struct neighbour it gets, n->dev
is an ipoib device so for example netdev_priv(n->dev) would be of type struct
ipoib_dev_priv.
To fix it, this patch adds a dev field to struct ipoib_neigh which is used
instead of the struct neighbour dev one.
Signed-off-by
Dotan Barak wrote:
> Hi Moni.
>
> I tried to use the mthca module parameter: for example i tried to change
> the number of QPs.
>
> I got several failures when i used the HCA 25204:
> * sometimes i got the following error message (when using big values,
> for example 512K QPs):
> ib_mthca: :0
Dotan Barak wrote:
> Hi Moni.
>
> I tried to use the mthca module parameter: for example i tried to change
> the number of QPs.
>
> I got several failures when i used the HCA 25204:
> * sometimes i got the following error message (when using big values,
> for example 512K QPs):
> ib_mthca: :0
Vladimir Sokolovsky wrote:
> Hi Moni,
> Please review the following patch to ib-bonding.spec:
>
> Use %{_prefix} in RPM spec file instead of hard-coded /usr/local/ofed.
>
> Signed-off-by: Vladimir Sokolovsky <[EMAIL PROTECTED]>
> ---
>
> diff --git a/ib-bonding.spec b/ib-bonding.spec
> index
evice so for example netdev_priv(n->dev) would be of type struct
ipoib_dev_priv.
To fix it, this patch adds a dev field to struct ipoib_neigh which is used
instead of the struct neighbour dev one.
Signed-off-by: Moni Shoua <[EMAIL PROTECTED]>
Signed-off-by: Or Gerlitz <[EMAIL
Hi, Vlad,
Can you please pull this to OFED-1.2?
I guess this requires some changes in the build scripts and configuration files.
I'd be happy to help and any way I can to help with that. Please let me know.
thanks
- MoniS
Moni Shoua wrote:
> Originally, bonding is a High Availability
Michael S. Tsirkin wrote:
>>>
>>>Just to clarify - you previously mentionned you saw problems with 2.6.16
>>>backport. Is this an issue you see with 2.6.20 as well?
>>
>>Yes, the same thing happens with kernel 2.6.20. However, the patch for 2.6.20
>>looks a little bit different. I will post it toda
>
>
> Just to clarify - you previously mentionned you saw problems with 2.6.16
> backport. Is this an issue you see with 2.6.20 as well?
Yes, the same thing happens with kernel 2.6.20. However, the patch for 2.6.20
looks a little bit different. I will post it today or tommorow.
>
> Also - in y
ighbour dev one.
Signed-off-by: Moni Shoua <[EMAIL PROTECTED]>
Signed-off-by: Or Gerlitz <[EMAIL PROTECTED]>
ipoib.h |3 ++-
ipoib_main.c | 22 +++---
ipoib_multicast.c |2 +-
3 files changed, 14 insertions(+), 13 deletions(-)
---
Index: openib-1.1/d
Originally, bonding is a High Availability solution for Ethernet network
interfaces.
It is a module that implements a virtual network device (not bounded to
hardware) and enslaves "real" devices. Bonding device controls its slaves
according
to the bonding policy and the slave's health.
I am add
> Unless you can come up with a way that makes sure that all skbs are
> completed even in low-traffic situations, I don't think this is
> mergeable -- it's just too much of a usability nightmare to have a
> flag that is essentially "break some workloads in a mysterious way to
> make some benchmark
> Thinking about this more - why does this patch help some benchmarks?
> The amount of work it takes for the hardware to generate a completion
> is likely negligeable, and we still are scanning the same amount
> of TX WRs in a loop to unmap/free them.
This makes sense but I think you should also c
Michael S. Tsirkin wrote:
Tests with iperf and netperf for unicast and multicast destinations show
an improvement in the ability of user applications to xmit packets.
Examples: Number of successful writes as reported by 30 seconds UDP_STREAM
of 100 byte packets.
Tested wi
Michael S. Tsirkin wrote:
Tests with iperf and netperf for unicast and multicast destinations show
an improvement in the ability of user applications to xmit packets.
Examples: Number of successful writes as reported by 30 seconds UDP_STREAM
of 100 byte packets.
Tested wi
Michael S. Tsirkin wrote:
>>Tests with iperf and netperf for unicast and multicast destinations show
>>an improvement in the ability of user applications to xmit packets.
>>
>>Examples: Number of successful writes as reported by 30 seconds UDP_STREAM of
>>100 byte packets.
>>Tested with netperf o
Michael S. Tsirkin wrote:
>>I don't think that holding the skb too long is a trigger for somethink.
>
>
>
> Are you sure? We are not talking about too long here - unsignalled TX packet
> will never get a completion. As far as I can see, __kfree_skb will
> 1. call dst_release - so this patch mig
Michael S. Tsirkin wrote:
>>This patch implements selective tx signaling for IPoIB.
>
>
> Let's assume that the last tx packet you have sent is marked unsignalled.
> Since you never free the skb, won't the TX watchdog get triggered?
>
AFAIK, tx_timeout is called when (jiffies - dev->trans_start
Tests with iperf and netperf for unicast and multicast destinations show
an improvement in the ability of user applications to xmit packets.
Examples: Number of successful writes as reported by 30 seconds UDP_STREAM of
100 byte packets.
Tested with netperf on Dual CPU (64bit Intel Xeon 3GHz) ru
insertions(+), 14 deletions(-)
Signed-off-by: Moni Shoua <[EMAIL PROTECTED]>
---
Index: infiniband/drivers/infiniband/ulp/ipoib/ipoib.h
===
--- infiniband.orig/drivers/infiniband/ulp/ipoib/ipoib.h2007-01-07
15:39:49.421190
From: Leonid Arsh [EMAIL PROTECTED]>
Adds module parameters that enable settting some of the HCA
profile values
Signed-off-by: Leonid Arsh <[EMAIL PROTECTED]>
Signed-off-by: Moni Shoua <[EMAIL PROTECTED]>
---
mthca_main.c | 139
Roland Dreier wrote:
>The patch is line-wrapped and bizarrely corrupted and won't apply, eg:
>
> > + mthca_warn(mdev, "num_qp rounded to power of 2 (%d).\n",
> > + default_profile.num_qp); +}
>
>This is completely unnecessary:
>
> > +#define to_up_power_of_2(x) (x
From: Leonid Arsh <[EMAIL PROTECTED]>
Adds module parameters that enable settting some of the HCA
profile values.
Signed-off-by: Leonid Arsh <[EMAIL PROTECTED]>
Signed-off-by: Moni Shoua <[EMAIL PROTECTED]>
---
mthca_main.c | 104
Hi,
A few months ago, Leonid Arsh submitted a patch to mthca that enables to
control some of the HCA profile values.
This patch was discussed here (see references below) but wasn't accepted
and somehow got lost and I'd like to re-submit it.
http://openib.org/pipermail/openib-general/2006-May/02
Moni Shoua wrote:
>Hi,
>A few months ago, Leonid Arsh submitted a patch to mthca that enables to
>control some of the HCA profile values.
>This patch was discussed here (see references below) but wasn't accepted
>and somehow got lost and I'd like to re-submit it.
>
Hi,
A few months ago, Leonid Arsh submitted a patch to mthca that enables to
control some of the HCA profile values.
This patch was discussed here (see references below) but wasn't accepted
and somehow got lost and I'd like to re-submit it.
http://openib.org/pipermail/openib-general/2006-May/02
Michael S. Tsirkin wrote:
>I tried using ifconfig to limit the ipoib mtu.
>Once I do this on *either* both server and client, or only on the client side,
>UDP seems to stop working:
>
>#ifconfig ib0 mtu 512
>#netperf -c -C -H 11.4.3.68 -f M -t UDP_STREAM
>UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0
Vladimir Sokolovsky wrote:
>
> Ramachandra K wrote:
>
>> Moni Shoua wrote:
>>
>>> We already tried to go this way and found that a local
>>> Module.symvers is not always generated (but we might have missed
>>> something though).
>>> I sug
hen in order to compile external module copy this Modules.symvers to
> the directory where external module is build.
>
> Regards,
> Vladimir
>
>
> Moni Shoua wrote:
>
>> We managed to avoid rebuilding the kernel to solve this issue.
>>
>> Before building
We managed to avoid rebuilding the kernel to solve this issue.
Before building any IB dependant modules (out of OFED) it is required to
update the Module.symvers.
The new values for the symbol CRCs can be taken from the modules
themselves ( nm IB_MODULE |grep __crc_)
When Module.symvers is up-to-d
Scott Weitzenkamp (sweitzen) wrote:
OFED
1.0 rc3 on RHEL4 U3. IPoIB is working, but I just noticed the HWaddr
is 00-00-00-00-00-00-00-00-00-00-00-00-00-00-0, shouldn't this have the
GID?
[EMAIL PROTECTED] ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:13:72:50:B7:D1
Hi,
Belwo is a suggested patch that makes ib_query_device (or more
precisely mthca_query device) to return the number of max_map_per_fmr
instead of zero.
This is used by ib_create_fmr_pool as the number for maximum allowed FMR
remaps instead of the constant IB_FMR_MAX_REMAPS.
Since this is o
James Lentini wrote:
Arlin,
This email was garbled. I'm 99% certain it was from you, but the from
field reads "Moni Shoua":
http://openib.org/pipermail/openib-general/2006-March/018318.html
The patch was also mangled.
Could you resend please?
Thanks,
james
On Wed, 15
Davis, Arlin R wrote:
James,
I am in the process of building the autotools stuff for DAT and DAPL so
it builds exactly like the rest of OpenIB user libraries. I should have
something by the end of the day or tomorrow first thing.
-arlin
-Original Message-
From: James Lentini [mai
Davis, Arlin R wrote:
James,
I am in the process of building the autotools stuff for DAT and DAPL so
it builds exactly like the rest of OpenIB user libraries. I should have
something by the end of the day or tomorrow first thing.
-arlin
-Original Message-
From: James Lentini [mai
Davis, Arlin R wrote:
James,
I am in the process of building the autotools stuff for DAT and DAPL so
it builds exactly like the rest of OpenIB user libraries. I should have
something by the end of the day or tomorrow first thing.
-arlin
-Original Message-
From: James Le
s a bug of getcfg, bug in IPoIB or just a wrong IP
configuration?
thanks
____
Moni
Shoua | +972-9-9718630 (o) | +072-52-8232979 (m)
SW
Engineer, Mainstream IB host stack
Voltaire
– The Grid Bac
41 matches
Mail list logo
