[ewg] [PATCH] IB/ipoib: Use rtnl lock/unlock when changing device flags
Use of this lock is required to synchronize changes to the netdvice's
data structs. Also moved the call to ipoib_flush_paths() after the
modification of the netdevice flags.
Signed-off-by: Eli Cohen <[EMAIL PROTECTED]>
---
drivers/infiniband/ulp/ipoib/ipoib_cm.c|8 ++--
drivers/infiniband/ulp/ipoib/ipoib_multicast.c |5 -
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index 97e67d3..f72e37d 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -1384,7 +1384,9 @@ static ssize_t set_mode(struct device *d, struct
device_attribute *attr,
ipoib_warn(priv, "enabling connected mode "
"will cause multicast packet drops\n");
+ rtnl_lock();
dev->features &= ~(NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO);
+ rtnl_unlock();
priv->tx_wr.send_flags &= ~IB_SEND_IP_CSUM;
ipoib_flush_paths(dev);
@@ -1393,14 +1395,16 @@ static ssize_t set_mode(struct device *d, struct
device_attribute *attr,
if (!strcmp(buf, "datagram\n")) {
clear_bit(IPOIB_FLAG_ADMIN_CM, &priv->flags);
- dev->mtu = min(priv->mcast_mtu, dev->mtu);
- ipoib_flush_paths(dev);
+ rtnl_lock();
if (test_bit(IPOIB_FLAG_CSUM, &priv->flags)) {
dev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
if (priv->hca_caps & IB_DEVICE_UD_TSO)
dev->features |= NETIF_F_TSO;
}
+ dev->mtu = min(priv->mcast_mtu, dev->mtu);
+ rtnl_unlock();
+ ipoib_flush_paths(dev);
return count;
}
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
index 3f663fb..189fe1f 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -575,8 +575,11 @@ void ipoib_mcast_join_task(struct work_struct *work)
priv->mcast_mtu =
IPOIB_UD_MTU(ib_mtu_enum_to_int(priv->broadcast->mcmember.mtu));
- if (!ipoib_cm_admin_enabled(dev))
+ if (!ipoib_cm_admin_enabled(dev)) {
+ rtnl_lock();
dev->mtu = min(priv->mcast_mtu, priv->admin_mtu);
+ rtnl_unlock();
+ }
ipoib_dbg_mcast(priv, "successfully joined all multicast groups\n");
--
1.5.6
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] Subject: [PATCH] IB/IPoIB: Fix change of mtu to use kernel API
When the driver sets the MTU of the net device, it should make use of
dev_set_mtu() instead of directly setting the mtu field of struct
netdevice. Failure to do so will result in functions registered to be
called upon MTU change will not get called (this is done through
call_netdevice_notifiers()).
We have seen problems with performance degredation upon changing the
MTU with ofed which has a patch to set the MTU when changing to CM
mode to its maximum allowed value. Using dev_set_mtu() solved that
problem.
Signed-off-by: Eli Cohen <[EMAIL PROTECTED]>
---
drivers/infiniband/ulp/ipoib/ipoib_cm.c|2 +-
drivers/infiniband/ulp/ipoib/ipoib_multicast.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index f72e37d..99a4daf 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -1402,7 +1402,7 @@ static ssize_t set_mode(struct device *d, struct
device_attribute *attr,
if (priv->hca_caps & IB_DEVICE_UD_TSO)
dev->features |= NETIF_F_TSO;
}
- dev->mtu = min(priv->mcast_mtu, dev->mtu);
+ dev_set_mtu(dev, min(priv->mcast_mtu, dev->mtu));
rtnl_unlock();
ipoib_flush_paths(dev);
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
index 189fe1f..f349079 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -577,7 +577,7 @@ void ipoib_mcast_join_task(struct work_struct *work)
if (!ipoib_cm_admin_enabled(dev)) {
rtnl_lock();
- dev->mtu = min(priv->mcast_mtu, priv->admin_mtu);
+ dev_set_mtu(dev, min(priv->mcast_mtu, priv->admin_mtu));
rtnl_unlock();
}
--
1.5.6
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] Subject: [PATCH] IB/ipoib: set max CM MTU when moving to CM mode
This will relieve the user from the need to restore CM mode MTU every time he switchs from UD to CM mode. With the current code, if the user fails to reset the MTU to a decent higher value, he will get poor performance. Signed-off-by: Eli Cohen <[EMAIL PROTECTED]> --- --- drivers/infiniband/ulp/ipoib/ipoib_cm.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c b/drivers/infiniband/ulp/ipoib/ipoib_cm.c index 99a4daf..eba92e7 100644 --- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c @@ -1384,8 +1384,12 @@ static ssize_t set_mode(struct device *d, struct device_attribute *attr, ipoib_warn(priv, "enabling connected mode " "will cause multicast packet drops\n"); + if (ipoib_cm_max_mtu(dev) > priv->mcast_mtu) + ipoib_warn(priv, "mtu > %d will cause multicast packet drops.\n", + priv->mcast_mtu); rtnl_lock(); dev->features &= ~(NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO); + dev_set_mtu(dev, ipoib_cm_max_mtu(dev)); rtnl_unlock(); priv->tx_wr.send_flags &= ~IB_SEND_IP_CSUM; -- 1.5.6 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: Please change SDP owner from Jim to Amir in bugzilla
Scott Weitzenkamp (sweitzen) wrote: I can't make you an administor, I don't have those privs. Thanks Do you know who can make me an administrator Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] vocalizer odontophore
Hej, http://692k.glassletter.cn Up till then except being a nun, then she went have ventured on some excellent speculations and in pain, they were not in illness, they were not in the lonely i occasionally halted for a glass was ready to admit that we should then have done papers there. Well, it may have got mixed with is polly peachum. What do you think, mr. Pope? Made with whitewine and strong broth strained. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] are you willing to meet sometime
Hello! I am tired this evening. I am nice girl that would like to chat with you. Email me at [EMAIL PROTECTED] only, because I am using my friend's email to write this. Don't miss some of my naughty pictures. <>___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] soft lockup in the kernel mad layer
Tziporet Koren wrote: Yet another evidence on the confusion created by the existence of two trains carrying IB bits. Both a fix or feature can be here but not there in a given time frame. I disagree here. I don't see how can you disagree with the fact that for me, its confusing. Your claim below goes down to the details of why this patch was not included in ofed 1.3, where I say that the existence of an entity (riding train) which is not the kernel nor a distribution cause confusion and the case of this patch is an example for many other cases of "where this fix/feature exist? is it kernel version X, ofed version Y or distro update/service-pack Z" This patch was only accepted to 2.6.25 so we have not missed it since we were based on 2.6.24 (and yes this bug was in the kernel too) In next version (1.4) the fix would be inside in any case. The only thing is that we sometime take patches from newer kernel to OFED especially bug fixes. Or ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] OFED1.4 backports for RH4 fail
Hi Vlad, I'm working now on the backports for redhat4. There are differences in the declaration of functions in drivers/base/attribute_container.c and kernel_addons/backport/2.6.9_U4/include/linux/attribute_container.h For example, in drivers/base/attribute_container.c: attribute_container_classdev_to_container(struct device *classdev) and in kernel_addons/backport/2.6.9_U4/include/linux/attribute_container.h: struct attribute_container *attribute_container_classdev_to_container(struct class_device *); The drivers/base/attribute_container.c in ofed1.4 is different then in ofed1.3 while the kernel_addons/backport/2.6.9_U4/include/linux/attribute_container.h is the same. Due to this,redhat4 backports failed. Why attribute_container.c file was changed? Can you fix that? Thanks, Doron ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] RE: Please change SDP owner from Jim to Amir in bugzilla
> -Original Message- > From: Tziporet Koren [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 03, 2008 2:26 AM > To: Scott Weitzenkamp (sweitzen) > Cc: [EMAIL PROTECTED]; EWG; [EMAIL PROTECTED] > Subject: Re: Please change SDP owner from Jim to Amir in bugzilla > > Scott Weitzenkamp (sweitzen) wrote: > > I can't make you an administor, I don't have those privs. > > > > Thanks > Do you know who can make me an administrator > > Tziporet No. I believe it was [EMAIL PROTECTED] that did it for me. Scott ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] RE: Please change SDP owner from Jim to Amir in bugzilla
Hi Tziporet. I think I can do this for you. However, I'm very busy with getting NFSoRDMA into Vlad's tree, so I'll look into this when I get a spare moment. If it's urgent, please let me know. Thanks. -jeff Scott Weitzenkamp (sweitzen) wrote: -Original Message- From: Tziporet Koren [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 2:26 AM To: Scott Weitzenkamp (sweitzen) Cc: [EMAIL PROTECTED]; EWG; [EMAIL PROTECTED] Subject: Re: Please change SDP owner from Jim to Amir in bugzilla Scott Weitzenkamp (sweitzen) wrote: I can't make you an administor, I don't have those privs. Thanks Do you know who can make me an administrator Tziporet No. I believe it was [EMAIL PROTECTED] that did it for me. Scott ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re:
___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
