* Fw: rcu warning
From: Paul E. McKenney @ 2010-09-22 21:44 UTC (permalink / raw)
To: eric.dumazet; +Cc: akpm, netdev
> Date: Wed, 22 Sep 2010 13:52:28 -0700
> From: Andrew Morton <akpm@linux-foundation.org>
> To: "Paul E. McKenney" <paulmck@us.ibm.com>
> Subject: rcu warning
> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; x86_64-pc-linux-gnu)
>
> [ 56.803750]
> [ 56.803752] ===================================================
> [ 56.804082] [ INFO: suspicious rcu_dereference_check() usage. ]
> [ 56.804249] ---------------------------------------------------
> [ 56.804421] include/linux/inetdevice.h:219 invoked rcu_dereference_check() without protection!
> [ 56.804708]
> [ 56.804709] other info that might help us debug this:
> [ 56.804710]
> [ 56.805183]
> [ 56.805184] rcu_scheduler_active = 1, debug_locks = 1
> [ 56.805501] 3 locks held by kworker/0:1/0:
> [ 56.805664] #0: (&in_dev->mr_ifc_timer){+.-...}, at: [<ffffffff81042466>] run_timer_softirq+0xfd/0x226
> [ 56.806126] #1: (&in_dev->mc_list_lock){++.-..}, at: [<ffffffff8133e81d>] igmp_ifc_timer_expire+0x2a/0x221
> [ 56.806588] #2: (&(&im->lock)->rlock){+.-...}, at: [<ffffffff8133e948>] igmp_ifc_timer_expire+0x155/0x221
> [ 56.807043]
> [ 56.807044] stack backtrace:
> [ 56.807364] Pid: 0, comm: kworker/0:1 Not tainted 2.6.36-rc5-mm1 #1
> [ 56.807561] Call Trace:
> [ 56.807723] <IRQ> [<ffffffff8105b88b>] lockdep_rcu_dereference+0x99/0xa2
> [ 56.807948] [<ffffffff8130dc66>] __ip_route_output_key+0x34f/0xb19
> [ 56.808120] [<ffffffff8130d94a>] ? __ip_route_output_key+0x33/0xb19
> [ 56.814367] [<ffffffff8130e453>] ip_route_output_flow+0x23/0x1ee
> [ 56.814536] [<ffffffff8130e62c>] ip_route_output_key+0xe/0x10
> [ 56.814704] [<ffffffff8133e19d>] igmpv3_newpack+0x7f/0x1c2
> [ 56.814873] [<ffffffff8133e30d>] add_grhead+0x2d/0x94
> [ 56.815039] [<ffffffff8133e6c2>] add_grec+0x34e/0x38c
> [ 56.815206] [<ffffffff8133e9a8>] igmp_ifc_timer_expire+0x1b5/0x221
> [ 56.815375] [<ffffffff810424e8>] run_timer_softirq+0x17f/0x226
> [ 56.815547] [<ffffffff81042466>] ? run_timer_softirq+0xfd/0x226
> [ 56.815715] [<ffffffff8133e7f3>] ? igmp_ifc_timer_expire+0x0/0x221
> [ 56.815885] [<ffffffff8103ca8f>] __do_softirq+0xa5/0x13a
> [ 56.816051] [<ffffffff8100390c>] call_softirq+0x1c/0x28
> [ 56.816219] [<ffffffff81004eba>] do_softirq+0x38/0x82
> [ 56.816385] [<ffffffff8103c9e8>] irq_exit+0x47/0x49
> [ 56.816553] [<ffffffff81019ce3>] smp_apic_timer_interrupt+0x88/0x96
> [ 56.816722] [<ffffffff810033d3>] apic_timer_interrupt+0x13/0x20
> [ 56.816888] <EOI> [<ffffffff8138607a>] ? __atomic_notifier_call_chain+0x0/0x84
> [ 56.817215] [<ffffffff81009a9b>] ? mwait_idle+0x65/0x71
> [ 56.817382] [<ffffffff81009a91>] ? mwait_idle+0x5b/0x71
> [ 56.817549] [<ffffffff810014ca>] cpu_idle+0x48/0x66
> [ 56.817716] [<ffffffff8137b4da>] start_secondary+0x1b9/0x1bd
> [ 56.817883] [<ffffffff8137b321>] ? start_secondary+0x0/0x1bd
Hello, Eric,
In linux/master, there is an rcu_read_lock_bh() in the call path, but
an rcu_dereference() instead of an rcu_dereference_bh(). Thoughts?
(I have asked Andrew what kernel this is against -- I don't see the
rcu_read_lock() that I would expect to see in the lockdep output.)
Thanx, Paul
> We seem to be getting way too many of these.
>
> ----- End forwarded message -----
^ permalink raw reply
* Re: igmp: Staggered igmp report intervals for unsolicited igmp reports
From: David Stevens @ 2010-09-22 21:41 UTC (permalink / raw)
To: Christoph Lameter
Cc: David S. Miller, linux-rdma@vger.kernel.org,
netdev@vger.kernel.org, Bob Arendt
In-Reply-To: <alpine.DEB.2.00.1009221631520.32661@router.home>
Christoph Lameter <cl@linux.com> wrote on 09/22/2010 02:33:14 PM:
This can address issues where joins are slow because the initial join is
> frequently lost.
>
> Also increment the frequency so that we get a 10 reports send over a
> few seconds.
Except you want to conform and not conform at the same time. :-)
IGMPv2 should be: default count 2, interval 10secs
IGMPv3 should be: default count 2, interval 1sec
...and no way is it a good idea to send 10 unsolicited reports on an
Ethernet.
I think system-wide defaults must be as suggested (which allows for
v3 being shortened to 1sec, but not v2) and if you want to use longer
values, you should have either a *per-interface* tunable [ie, the default
value for your interface only] or make these per-interface variables and
have the IB code bump them up for IB interfaces only. An attached
Ethernet on the same system shouldn't be using larger values unless
bumped for some reason by an administrator.
There is no problem with current values on Ethernet; lets not create
one. :-)
+-DLS
^ permalink raw reply
* Re: [PATCH 2/2] siw: Add support for CRC32C offload instruction using libcrypto crc32c-intel
From: Nicholas A. Bellinger @ 2010-09-22 21:38 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: linux-kernel, netdev, linux-rdma, Bernard Metzler
In-Reply-To: <20100922211808.GJ11157@obsidianresearch.com>
On Wed, 2010-09-22 at 15:18 -0600, Jason Gunthorpe wrote:
> [cc list chopped]
>
> On Wed, Sep 22, 2010 at 02:00:41PM -0700, Nicholas A. Bellinger wrote:
> > On Wed, 2010-09-22 at 14:59 -0600, Jason Gunthorpe wrote:
> > > On Wed, Sep 22, 2010 at 01:38:21PM -0700, Nicholas A. Bellinger wrote:
> > >
> > > > Indeed, this would clean up the explict RX/TX CRC32C case quite a
> > > > bit.. Unfortuately I am too busy with other items atm to cook up
> > > > this patch, but I would be happy to test it if someone wants to take
> > > > it. ;)
> > >
> > > Do you even need to do anything at all? crc32c is provided by
> > > crc32c-intel at a higher priority already, so it should be used if it
> > > is available..
> >
> > I believe with the current libcrypto code that consumers are still
> > required to explictly ask for crc32c-intel offload.
>
> Really? It all looks OK to me.. What does your /proc/crypto say on a
> system with crc32c-intel support?
After a fresh boot /proc/crypto looks like:
name : stdrng
driver : krng
module : kernel
priority : 200
refcnt : 1
selftest : passed
type : rng
seedsize : 0
name : crc32c
driver : crc32c-generic
module : kernel
priority : 100
refcnt : 2
selftest : passed
type : shash
blocksize : 1
digestsize : 4
name : sha1
driver : sha1-generic
module : kernel
priority : 0
refcnt : 1
selftest : passed
type : shash
blocksize : 64
digestsize : 20
Once I start up the LIO-Target stack and some iSCSI Initiators login
and request crc32c-intel using crypto_alloc_hash() using a method similar
to what this patch for Softiwarp does, the following appears in at the top
of /proc/crypto:
name : crc32c
driver : crc32c-intel
module : crc32c_intel
priority : 200
refcnt : 5
selftest : passed
type : shash
blocksize : 1
digestsize : 4
So I think the main bit here is the ability to request crc32c-intel.ko first,
and then fall back to crc32c.ko when the former is not available on CONFIG_X86.
Best,
--nab
^ permalink raw reply
* Re: igmp: Staggered igmp report intervals for unsolicited igmp reports
From: Christoph Lameter @ 2010-09-22 21:33 UTC (permalink / raw)
To: Bob Arendt
Cc: David Stevens, David S. Miller,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <4C9A6D87.2000103-x0S3BwdUo6DQT0dZR+AlfA@public.gmane.org>
On Wed, 22 Sep 2010, Bob Arendt wrote:
> multicast traffic is received. While IGMPv2 defines an "Unsolicited Report
> Interval" default of 10 seconds, it appears that this is a significant enough
> issue that the later IGMPv3 document calls out a default of 1 second, and
> goes on to define a "Robustness Variable" and talks about the same case that
> Christoph is trying to mitigate.
Actually that suggests a different way to reach the same goal:
Subject: igmp: Make unsolicited report interval conform to RFC3376
RFC3376 specifies a shorter time interval for sending igmp joins.
This can address issues where joins are slow because the initial join is
frequently lost.
Also increment the frequency so that we get a 10 reports send over a
few seconds.
Signed-off-by: Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>
---
net/ipv4/igmp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6/net/ipv4/igmp.c
===================================================================
--- linux-2.6.orig/net/ipv4/igmp.c 2010-09-22 16:28:17.000000000 -0500
+++ linux-2.6/net/ipv4/igmp.c 2010-09-22 16:28:54.000000000 -0500
@@ -114,9 +114,9 @@
#define IGMP_V1_Router_Present_Timeout (400*HZ)
#define IGMP_V2_Router_Present_Timeout (400*HZ)
-#define IGMP_Unsolicited_Report_Interval (10*HZ)
+#define IGMP_Unsolicited_Report_Interval (HZ)
#define IGMP_Query_Response_Interval (10*HZ)
-#define IGMP_Unsolicited_Report_Count 2
+#define IGMP_Unsolicited_Report_Count 10
#define IGMP_Initial_Report_Delay (1)
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: igmp: Staggered igmp report intervals for unsolicited igmp reports
From: Christoph Lameter @ 2010-09-22 21:26 UTC (permalink / raw)
To: David Stevens; +Cc: David S. Miller, linux-rdma, netdev, Bob Arendt
In-Reply-To: <OFAB7DE0DE.BD125180-ON882577A6.006F6717-882577A6.00713062@us.ibm.com>
On Wed, 22 Sep 2010, David Stevens wrote:
> > The protocol does not specificy the intervals during unsolicited igmp
> > sends. It only specifies the intervals as a result of a igmp query.
>
> RFC 3376:
> " To cover the possibility of the State-Change Report being missed by
> one or more multicast routers, it is retransmitted [Robustness
> Variable] - 1 more times, at intervals chosen at random from the
> range (0, [Unsolicited Report Interval])."
> and
> "8.11. Unsolicited Report Interval
>
> The Unsolicited Report Interval is the time between repetitions of a
> host's initial report of membership in a group. Default: 1 second."
Hmmm looks like I looked at the earlier RFC 2236 3) (was not really
interested in IGMP v3, IGMPv2 is run).
When a host joins a multicast group, it should immediately transmit
an unsolicited Version 2 Membership Report for that group, in case it
is the first member of that group on the network. To cover the
possibility of the initial Membership Report being lost or damaged,
it is recommended that it be repeated once or twice after short
delays [Unsolicited Report Interval]. (A simple way to accomplish
this is to send the initial Version 2 Membership Report and then act
as if a Group-Specific Query was received for that group, and set a
timer appropriately).
The new Unsolicited Report Interval is promising. We need to support that?
> > The device is ready. Its just the multicast group that has not been
> > established yet.
> Well, if you know that's going to happen with your device, then
> again, why not queue them on start up until you have indication that
> the group has been established, or delay in the driver.
> You're changing IGMP for all device types to fix a problem in
> only one.
>
> > There also cannot be any storm since any unsolicited igmp report by any
> > system will stop the unsolicited igmp reports by any other system.
>
> Not if they are simultaneous, which is exactly when it is a
> problem. :-)
But then they are not simulateneous since there is a fuzz factor.
> > These are *unsolicited* igmp reports. There is *no* querier supplied
> data
> > yet. The first querier supplied data (or any other unsolicited igmp
> > report) will immediately stop the unsolicited reports and then will
> > continue to respond in randomized intervals based on the data that the
> > querier has supplied.
>
> There are initial values, which are currently constants, but it'd
> be (more) reasonable to turn those into per-interface tunables or
> per-interface initial values with IB interfaces using larger values.
>
> IGMP_Unsolicited_Report_Count (default 2)
> IGMP_Unsolicited_Report_Interval (default 10secs which is 10x larger,as
> you want, than the RFC suggests).
Ahhh... Interesting..... 1 second now? That is much better and would avoid
long drawn out joins due to the long delays.
^ permalink raw reply
* Re: [PATCH 2/2] siw: Add support for CRC32C offload instruction using libcrypto crc32c-intel
From: Jason Gunthorpe @ 2010-09-22 21:18 UTC (permalink / raw)
To: Nicholas A. Bellinger; +Cc: linux-kernel, netdev, linux-rdma, Bernard Metzler
In-Reply-To: <1285189241.1849.112.camel@haakon2.linux-iscsi.org>
[cc list chopped]
On Wed, Sep 22, 2010 at 02:00:41PM -0700, Nicholas A. Bellinger wrote:
> On Wed, 2010-09-22 at 14:59 -0600, Jason Gunthorpe wrote:
> > On Wed, Sep 22, 2010 at 01:38:21PM -0700, Nicholas A. Bellinger wrote:
> >
> > > Indeed, this would clean up the explict RX/TX CRC32C case quite a
> > > bit.. Unfortuately I am too busy with other items atm to cook up
> > > this patch, but I would be happy to test it if someone wants to take
> > > it. ;)
> >
> > Do you even need to do anything at all? crc32c is provided by
> > crc32c-intel at a higher priority already, so it should be used if it
> > is available..
>
> I believe with the current libcrypto code that consumers are still
> required to explictly ask for crc32c-intel offload.
Really? It all looks OK to me.. What does your /proc/crypto say on a
system with crc32c-intel support?
Jason
^ permalink raw reply
* Re: igmp: Staggered igmp report intervals for unsolicited igmp reports
From: Bob Arendt @ 2010-09-22 20:56 UTC (permalink / raw)
To: Christoph Lameter
Cc: David Stevens, David S. Miller, linux-rdma@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <alpine.DEB.2.00.1009221448460.32661@router.home>
On 09/22/2010 12:58 PM, Christoph Lameter wrote:
> On Wed, 22 Sep 2010, David Stevens wrote:
>> 3) I don't think it's a good idea to make up intervals, and especially
>> non-randomized ones. The probability of getting all minimum
>> intervals
>> is very low (which goes back to #1) and sending fixed intervals
>> may
>> introduce a problem (packet storms) that isn't there per RFC.
>> These
>> fixed intervals can also be either way too long or way too short,
>> depending on link characteristics they don't account for. Leaving
>> the intervals randomized based on querier-supplied data seems much
>> more appropriate to me.
>
> These are *unsolicited* igmp reports. There is *no* querier supplied data
> yet. The first querier supplied data (or any other unsolicited igmp
> report) will immediately stop the unsolicited reports and then will
> continue to respond in randomized intervals based on the data that the
> querier has supplied.
>
>
There certainly seems to be some backing for part of Christoph's concept in
the IETF rfc's. I've posted the relevant sections below. IGMPv2 doesn't specify
a limit on retransmissions of an unsolicited Join, only that they stop once
multicast traffic is received. While IGMPv2 defines an "Unsolicited Report
Interval" default of 10 seconds, it appears that this is a significant enough
issue that the later IGMPv3 document calls out a default of 1 second, and
goes on to define a "Robustness Variable" and talks about the same case that
Christoph is trying to mitigate.
However, both rfc's *do* specify that the random timers should be used based
on a value called the "unsolicited report interval".
Perhaps implementing the IGMPv3 capability with kernel parameters for an
"unsolicited report interval" and "robustness variable" would satisfy
Christoph's issue?
-Bob Arendt
rfc2236 IGMPv2 =============================
Section 3 .... page 4 para 2
When a host joins a multicast group, it should immediately transmit
an unsolicited Version 2 Membership Report for that group, in case it
is the first member of that group on the network. To cover the
possibility of the initial Membership Report being lost or damaged,
it is recommended that it be repeated once or twice after short
delays [Unsolicited Report Interval].
Section 6 ... page 8 para 4
- "start timer" for the group on the interface, using a delay value
chosen uniformly from the interval (0, Max Response Time], where
Max Response time is specified in the Query. If this is an
unsolicited Report, the timer is set to a delay value chosen
uniformly from the interval (0, [Unsolicited Report Interval] ].
8.10. Unsolicited Report Interval (page 18)
The Unsolicited Report Interval is the time between repetitions of a
host's initial report of membership in a group. Default: 10 seconds.
rfc3376 IGMPv3 ============================
Section 5.1 page 19, near end
(note - unsolicited Join is a type of State-Change report)
To cover the possibility of the State-Change Report being missed by
one or more multicast routers, it is retransmitted [Robustness
Variable] - 1 more times, at intervals chosen at random from the
range (0, [Unsolicited Report Interval]).
8.11. Unsolicited Report Interval (page 41)
The Unsolicited Report Interval is the time between repetitions of a
host's initial report of membership in a group. Default: 1 second.
8.1. Robustness Variable (page 39)
The Robustness Variable allows tuning for the expected packet loss on
a network. If a network is expected to be lossy, the Robustness
Variable may be increased. IGMP is robust to (Robustness Variable -
1) packet losses. The Robustness Variable MUST NOT be zero, and
SHOULD NOT be one. Default: 2
8.14.1. Robustness Variable (page 41/42)
The Robustness Variable tunes IGMP to expected losses on a link.
IGMPv3 is robust to (Robustness Variable - 1) packet losses, e.g., if
the Robustness Variable is set to the default value of 2, IGMPv3 is
robust to a single packet loss but may operate imperfectly if more
losses occur. On lossy subnetworks, the Robustness Variable should
be increased to allow for the expected level of packet loss. However,
increasing the Robustness Variable increases the leave latency of the
subnetwork. (The leave latency is the time between when the last
member stops listening to a source or group and when the traffic
stops flowing.)
^ permalink raw reply
* Re: [PATCH 2/2] siw: Add support for CRC32C offload instruction using libcrypto crc32c-intel
From: Nicholas A. Bellinger @ 2010-09-22 21:00 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Andi Kleen, linux-kernel, netdev, linux-rdma, Bernard Metzler,
David Miller, Matthew Wilcox, Roland Dreier
In-Reply-To: <20100922205943.GI11157@obsidianresearch.com>
On Wed, 2010-09-22 at 14:59 -0600, Jason Gunthorpe wrote:
> On Wed, Sep 22, 2010 at 01:38:21PM -0700, Nicholas A. Bellinger wrote:
>
> > Indeed, this would clean up the explict RX/TX CRC32C case quite a
> > bit.. Unfortuately I am too busy with other items atm to cook up
> > this patch, but I would be happy to test it if someone wants to take
> > it. ;)
>
> Do you even need to do anything at all? crc32c is provided by
> crc32c-intel at a higher priority already, so it should be used if it
> is available..
I believe with the current libcrypto code that consumers are still
required to explictly ask for crc32c-intel offload.
>
> > > Need CPUID module auto probing. I have an older patch that needs
> > > some fixes.
>
> > Hmm, I don't see how that fits in here exactly. Would you mind
> > elaborating a bit..?
>
> Unless the module is loaded the optimized algorithm will not be
> available for automatic use. Maybe your patch causes it to autoload
> because of the by-name reference? Identifying modules to load by CPUID
> will let userspace auto load the appropriate ones based on CPU...
>
Correct, this patch is so that autoload of crc32c-intel.ko 'just works'
and we do the fallback to the legacy slicing by 1x crc32c.ko when the
former is not availabe.
But I definately agree with Andi here that we should just add a wrapper
around the crypto_alloc_hash() usage of crc32c-intel and crc32c for
libcrypto consumers..
Thanks for your comments Jason!
--nab
^ permalink raw reply
* Re: [PATCH 2/2] siw: Add support for CRC32C offload instruction using libcrypto crc32c-intel
From: Jason Gunthorpe @ 2010-09-22 20:59 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: Andi Kleen, linux-kernel, netdev, linux-rdma, Bernard Metzler,
David Miller, Matthew Wilcox, Roland Dreier
In-Reply-To: <1285187901.1849.85.camel-Y1+j5t8j3WgjMeEPmliV8E/sVC8ogwMJ@public.gmane.org>
On Wed, Sep 22, 2010 at 01:38:21PM -0700, Nicholas A. Bellinger wrote:
> Indeed, this would clean up the explict RX/TX CRC32C case quite a
> bit.. Unfortuately I am too busy with other items atm to cook up
> this patch, but I would be happy to test it if someone wants to take
> it. ;)
Do you even need to do anything at all? crc32c is provided by
crc32c-intel at a higher priority already, so it should be used if it
is available..
> > Need CPUID module auto probing. I have an older patch that needs
> > some fixes.
> Hmm, I don't see how that fits in here exactly. Would you mind
> elaborating a bit..?
Unless the module is loaded the optimized algorithm will not be
available for automatic use. Maybe your patch causes it to autoload
because of the by-name reference? Identifying modules to load by CPUID
will let userspace auto load the appropriate ones based on CPU...
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] atl1: zero out CMB and SBM in atl1_free_ring_resources
From: David Miller @ 2010-09-22 20:53 UTC (permalink / raw)
To: kronos.it; +Cc: netdev, atl1-devel, jcliburn, chris.snook, jie.yang
In-Reply-To: <20100922204231.GA1401@nb-core2.darkstar.lan>
From: Luca Tettamanti <kronos.it@gmail.com>
Date: Wed, 22 Sep 2010 22:42:31 +0200
> They are allocated in atl1_setup_ring_resources, zero out the pointers
> in atl1_free_ring_resources (like the other resources).
>
> Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
> Acked-by: Chris Snook <chris.snook@gmail.com>
Applied.
^ permalink raw reply
* RE: [PATCH] cxgbi: bug fixes and code cleanup
From: Karen Xie @ 2010-09-22 20:52 UTC (permalink / raw)
To: Mike Christie
Cc: netdev, linux-scsi, open-iscsi, Rakesh Ranjan, James.Bottomley,
davem
In-Reply-To: <4C9A627D.4060800@cs.wisc.edu>
Thanks, Mike.
I will fix the patch and break it into per change.
Karen
-----Original Message-----
From: Mike Christie [mailto:michaelc@cs.wisc.edu]
Sent: Wednesday, September 22, 2010 1:10 PM
To: Karen Xie
Cc: netdev@vger.kernel.org; linux-scsi@vger.kernel.org;
open-iscsi@googlegroups.com; Rakesh Ranjan;
James.Bottomley@HansenPartnership.com; davem@davemloft.net
Subject: Re: [PATCH] cxgbi: bug fixes and code cleanup
On 09/21/2010 11:09 AM, kxie@chelsio.com wrote:
> [PATCH] cxgbi: bug fixes and code cleanup
>
> From: Karen Xie<kxie@chelsio.com>
>
> The patch includes the following changes.
> - removed un-used code
> - renamed alloc_cpl() to alloc_wr().
> - fixed connecting over VLAN.
> - updated cxgb4i connection setting and pagepod programming.
Could you break up the patch into a patch per change next time?
> - read_lock(&csk->callback_lock);
> dskb = skb_peek(&csk->receive_queue);
> if (!dskb) {
>
read_unlock(&csk->callback_lock);
I think you also have to remove this read_unlock call.
^ permalink raw reply
* Re: [PATCH 1/2] atl1: fix resume
From: David Miller @ 2010-09-22 20:53 UTC (permalink / raw)
To: kronos.it; +Cc: netdev, atl1-devel, jcliburn, chris.snook, jie.yang
In-Reply-To: <20100922204158.GA1372@nb-core2.darkstar.lan>
From: Luca Tettamanti <kronos.it@gmail.com>
Date: Wed, 22 Sep 2010 22:41:58 +0200
> adapter->cmb.cmb is initialized when the device is opened and freed when
> it's closed. Accessing it unconditionally during resume results either
> in a crash (NULL pointer dereference, when the interface has not been
> opened yet) or data corruption (when the interface has been used and
> brought down adapter->cmb.cmb points to a deallocated memory area).
>
> Cc: stable@kernel.org
> Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
> Acked-by: Chris Snook <chris.snook@gmail.com>
Applied.
^ permalink raw reply
* [PATCH 2/2] atl1: zero out CMB and SBM in atl1_free_ring_resources
From: Luca Tettamanti @ 2010-09-22 20:42 UTC (permalink / raw)
To: netdev; +Cc: atl1-devel, jcliburn, chris.snook, jie.yang
In-Reply-To: <20100922.132341.48506736.davem@davemloft.net>
They are allocated in atl1_setup_ring_resources, zero out the pointers
in atl1_free_ring_resources (like the other resources).
Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
Acked-by: Chris Snook <chris.snook@gmail.com>
---
drivers/net/atlx/atl1.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/atlx/atl1.c b/drivers/net/atlx/atl1.c
index bbd6e30..c73be28 100644
--- a/drivers/net/atlx/atl1.c
+++ b/drivers/net/atlx/atl1.c
@@ -1251,6 +1251,12 @@ static void atl1_free_ring_resources(struct atl1_adapter *adapter)
rrd_ring->desc = NULL;
rrd_ring->dma = 0;
+
+ adapter->cmb.dma = 0;
+ adapter->cmb.cmb = NULL;
+
+ adapter->smb.dma = 0;
+ adapter->smb.smb = NULL;
}
static void atl1_setup_mac_ctrl(struct atl1_adapter *adapter)
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] atl1: fix resume
From: Luca Tettamanti @ 2010-09-22 20:41 UTC (permalink / raw)
To: netdev; +Cc: atl1-devel, jcliburn, chris.snook, jie.yang
In-Reply-To: <20100922.132341.48506736.davem@davemloft.net>
adapter->cmb.cmb is initialized when the device is opened and freed when
it's closed. Accessing it unconditionally during resume results either
in a crash (NULL pointer dereference, when the interface has not been
opened yet) or data corruption (when the interface has been used and
brought down adapter->cmb.cmb points to a deallocated memory area).
Cc: stable@kernel.org
Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
Acked-by: Chris Snook <chris.snook@gmail.com>
---
This time with mutt :)
drivers/net/atlx/atl1.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/atlx/atl1.c b/drivers/net/atlx/atl1.c
index 63b9ba0..bbd6e30 100644
--- a/drivers/net/atlx/atl1.c
+++ b/drivers/net/atlx/atl1.c
@@ -2847,10 +2847,11 @@ static int atl1_resume(struct pci_dev *pdev)
pci_enable_wake(pdev, PCI_D3cold, 0);
atl1_reset_hw(&adapter->hw);
- adapter->cmb.cmb->int_stats = 0;
- if (netif_running(netdev))
+ if (netif_running(netdev)) {
+ adapter->cmb.cmb->int_stats = 0;
atl1_up(adapter);
+ }
netif_device_attach(netdev);
return 0;
--
1.7.1
^ permalink raw reply related
* Re: software iwarp stack update
From: Steve Wise @ 2010-09-22 20:42 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: Bernard Metzler, linux-rdma, netdev, David Miller, Matthew Wilcox,
Andi Kleen
In-Reply-To: <1285187710.1849.82.camel@haakon2.linux-iscsi.org>
On 09/22/2010 03:35 PM, Nicholas A. Bellinger wrote:
> On Wed, 2010-09-22 at 10:19 +0200, Bernard Metzler wrote:
>
>> Earlier this year, we announced the availability of an open source,
>> full software implementation of the iWARP RDMA protocol stack - see
>> my email "software iwarp stack" from March 14th at the linux-rdma list
>> (http://www.mail-archive.com/linux-rdma@vger.kernel.org/msg02940.html)
>> While since then working on performance and stability, we provided
>> some source code updates. Current user and kernel code is available at
>> gitorious.org/softiwarp. Please see the CHANGES file in the
>> kernel/ directory for a summary of the most recent changes.
>>
>> For more convenient testing, the latest update now allows for a
>> stand-alone build of the kernel module without full kernel source
>> code access. We tested the code with kernel version 2.6.34. If
>> you are interested in a full software RDMA stack on Ethernet,
>> please try it out.
>>
>> In the hope of providing useful information, I put
>> netdev@vger.kernel.org on copy. Subscribers of this list,
>> please put me on private cc in case you reply or comment, since
>> I am not subscribed to the list.
>> We would be more than happy if you netdev folks would consider
>> a hardware independent RDMA kernel service as something useful and
>> potentially to be integrated into the mainline network stack.
>>
>> Why might it be useful?
>> A software RDMA stack makes the semantic advantages of
>> asynchronous and one-sided communication available while obsoleting
>> the need to deploy dedicated RDMA hardware or any protocol offloading
>> (while not matching the lowest delay numbers of real RDMA hardware).
>> Implementing the IETF's iWARP protocol stack on top of TCP kernel
>> sockets, softiwarp integrates with the open fabrics environment
>> and thus exports the RDMA kernel and user verbs interface.
>>
>> The efficiency of the Linux TCP/IP network stack together with intrinsic
>> advantages of the RDMA communication model (async. posting of work
>> and reaping of work completions, transfer of send buffer ownership
>> to the kernel which enables zero copy transmit, peer data placement
>> without application scheduling, one-sided remote read operations etc.)
>> can result in improved application-to-application performance and
>> less CPU load, while using the unchanged kernel TCP stack.
>>
>> A software RDMA stack might promote wider RDMA deployment,
>> since when using the host TCP stack, it enables RDMA semantic
>> independent of dedicated hardware. softiwarp peers with real
>> RNICs (tested with Chelsio's T3 adapter).
>>
>> softiwarp is still work in progress and we are very thankful for any
>> suggestions/comments/bug reports. Please advise how we should proceed
>> to bring the stack further to your attention. Would it be useful to
>> provide patches against the current stable kernel version or the next
>> release candidate?
>>
>>
> Hi Bernard,
>
> So what I would recommend doing here to make things more appealing to
> DaveM and other interested NetDev folks would be to clone a seperate
> tree from the net-2.6.git or net-next-2.6.git repositories and include
> the softiwarp/kernel.git code into a fresh 'in-kernel' clone tracking
> the latest netdev code, and then keep git rebase'ing against DaveM's
> last changes and update your local tree to the lastest netdev code.
>
> Of course you will want to remove all of the 'out of tree' LINUX_VERSION
> build macros and any other legacy bits to follow mainline kernel
> convention for your 'in-kernel' softiwarp tree.
>
>
And then post a patch series for review.
Steve.
^ permalink raw reply
* Re: [PATCH 2/2] siw: Add support for CRC32C offload instruction using libcrypto crc32c-intel
From: Andi Kleen @ 2010-09-22 20:39 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: linux-kernel, netdev, linux-rdma, Bernard Metzler, David Miller,
Matthew Wilcox, Roland Dreier
In-Reply-To: <1285187425-10950-1-git-send-email-nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org>
On 9/22/2010 10:30 PM, Nicholas A. Bellinger wrote:
> From: Nicholas Bellinger<nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org>
>
> This patch updates siw_create_qp() to check for the CONFIG_X86 + cpu_has_xmm4_2
> dependent use of the CRC32C instruction offload using libcrypto crc32c-intel.ko.
> This patch will by default use crc32c-intel when available, and fall back to the
> legacy slicing by 1x libcrypto crc32c.ko code when the instruction offload is not
> availabe.
I don't think every caller should handle checks like this. The crypto
layer should load the right driver
instead and provide the best driver under a generic algorithm name.
Need CPUID module auto probing. I have an older patch that needs some fixes.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] siw: Add support for CRC32C offload instruction using libcrypto crc32c-intel
From: Nicholas A. Bellinger @ 2010-09-22 20:38 UTC (permalink / raw)
To: Andi Kleen
Cc: linux-kernel, netdev, linux-rdma, Bernard Metzler, David Miller,
Matthew Wilcox, Roland Dreier
In-Reply-To: <4C9A698B.90806@linux.intel.com>
On Wed, 2010-09-22 at 22:39 +0200, Andi Kleen wrote:
> On 9/22/2010 10:30 PM, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger<nab@linux-iscsi.org>
> >
> > This patch updates siw_create_qp() to check for the CONFIG_X86 + cpu_has_xmm4_2
> > dependent use of the CRC32C instruction offload using libcrypto crc32c-intel.ko.
> > This patch will by default use crc32c-intel when available, and fall back to the
> > legacy slicing by 1x libcrypto crc32c.ko code when the instruction offload is not
> > availabe.
>
> I don't think every caller should handle checks like this. The crypto
> layer should load the right driver
> instead and provide the best driver under a generic algorithm name.
>
Indeed, this would clean up the explict RX/TX CRC32C case quite a bit..
Unfortuately I am too busy with other items atm to cook up this patch,
but I would be happy to test it if someone wants to take it. ;)
> Need CPUID module auto probing. I have an older patch that needs some fixes.
>
Hmm, I don't see how that fits in here exactly. Would you mind
elaborating a bit..?
Thanks!
--nab
^ permalink raw reply
* Re: igmp: Staggered igmp report intervals for unsolicited igmp reports
From: David Stevens @ 2010-09-22 20:36 UTC (permalink / raw)
To: Christoph Lameter
Cc: David S. Miller, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Bob Arendt
In-Reply-To: <alpine.DEB.2.00.1009221448460.32661-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org> wrote:
>
> On Wed, 22 Sep 2010, David Stevens wrote:
>
> > I feel your pain, but the protocol allows this to be 0 and all
> > of the unsolicited reports can be lost. I don't think adding a minimum
> > latency solves a general problem. Perhaps the device should queue some
>
> The protocol does not specificy the intervals during unsolicited igmp
> sends. It only specifies the intervals as a result of a igmp query.
RFC 3376:
" To cover the possibility of the State-Change Report being missed by
one or more multicast routers, it is retransmitted [Robustness
Variable] - 1 more times, at intervals chosen at random from the
range (0, [Unsolicited Report Interval])."
and
"8.11. Unsolicited Report Interval
The Unsolicited Report Interval is the time between repetitions of a
host's initial report of membership in a group. Default: 1 second."
> The device is ready. Its just the multicast group that has not been
> established yet.
Well, if you know that's going to happen with your device, then
again, why not queue them on start up until you have indication that
the group has been established, or delay in the driver.
You're changing IGMP for all device types to fix a problem in
only one.
> There also cannot be any storm since any unsolicited igmp report by any
> system will stop the unsolicited igmp reports by any other system.
Not if they are simultaneous, which is exactly when it is a
problem. :-)
>
> > > So unsolicited reports are send for an interval of at least a minute
> > > (reports are aborted if igmp reports or other info is seen).
> >
> > This is outside the protocol spec, and the intervals are
neither
> > random nor scaled based on any network performance metric.
>
> Where does it say that in the spec? Again this is an *unsolicited* igmp
> report.
See quotes above.
> These are *unsolicited* igmp reports. There is *no* querier supplied
data
> yet. The first querier supplied data (or any other unsolicited igmp
> report) will immediately stop the unsolicited reports and then will
> continue to respond in randomized intervals based on the data that the
> querier has supplied.
There are initial values, which are currently constants, but it'd
be (more) reasonable to turn those into per-interface tunables or
per-interface initial values with IB interfaces using larger values.
IGMP_Unsolicited_Report_Count (default 2)
IGMP_Unsolicited_Report_Interval (default 10secs which is 10x larger,as
you want, than the RFC suggests).
+-DLS
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] X.25 remove bkl in poll
From: David Miller @ 2010-09-22 20:36 UTC (permalink / raw)
To: andrew.hendry; +Cc: netdev
In-Reply-To: <1285118685.28503.46.camel@jaunty>
From: Andrew Hendry <andrew.hendry@gmail.com>
Date: Wed, 22 Sep 2010 11:24:45 +1000
> The x25_datagram_poll didn't add anything, removed it.
>
> Signed-off-by: Andrew Hendry <andrew.hendry@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] X.25 remove bkl in getsockname
From: David Miller @ 2010-09-22 20:36 UTC (permalink / raw)
To: andrew.hendry; +Cc: netdev
In-Reply-To: <1285118665.28503.44.camel@jaunty>
From: Andrew Hendry <andrew.hendry@gmail.com>
Date: Wed, 22 Sep 2010 11:24:25 +1000
>
> Signed-off-by: Andrew Hendry <andrew.hendry@gmail.com>
Applied.
^ permalink raw reply
* Re: software iwarp stack update
From: Nicholas A. Bellinger @ 2010-09-22 20:35 UTC (permalink / raw)
To: Bernard Metzler
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
David Miller, Matthew Wilcox, Andi Kleen
In-Reply-To: <OF64770AFC.B48EBEF2-ONC12577A6.002CC793-C12577A6.002DC569-Xeyd2O9EBijQT0dZR+AlfA@public.gmane.org>
On Wed, 2010-09-22 at 10:19 +0200, Bernard Metzler wrote:
> Earlier this year, we announced the availability of an open source,
> full software implementation of the iWARP RDMA protocol stack - see
> my email "software iwarp stack" from March 14th at the linux-rdma list
> (http://www.mail-archive.com/linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg02940.html)
> While since then working on performance and stability, we provided
> some source code updates. Current user and kernel code is available at
> gitorious.org/softiwarp. Please see the CHANGES file in the
> kernel/ directory for a summary of the most recent changes.
>
> For more convenient testing, the latest update now allows for a
> stand-alone build of the kernel module without full kernel source
> code access. We tested the code with kernel version 2.6.34. If
> you are interested in a full software RDMA stack on Ethernet,
> please try it out.
>
> In the hope of providing useful information, I put
> netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org on copy. Subscribers of this list,
> please put me on private cc in case you reply or comment, since
> I am not subscribed to the list.
> We would be more than happy if you netdev folks would consider
> a hardware independent RDMA kernel service as something useful and
> potentially to be integrated into the mainline network stack.
>
> Why might it be useful?
> A software RDMA stack makes the semantic advantages of
> asynchronous and one-sided communication available while obsoleting
> the need to deploy dedicated RDMA hardware or any protocol offloading
> (while not matching the lowest delay numbers of real RDMA hardware).
> Implementing the IETF's iWARP protocol stack on top of TCP kernel
> sockets, softiwarp integrates with the open fabrics environment
> and thus exports the RDMA kernel and user verbs interface.
>
> The efficiency of the Linux TCP/IP network stack together with intrinsic
> advantages of the RDMA communication model (async. posting of work
> and reaping of work completions, transfer of send buffer ownership
> to the kernel which enables zero copy transmit, peer data placement
> without application scheduling, one-sided remote read operations etc.)
> can result in improved application-to-application performance and
> less CPU load, while using the unchanged kernel TCP stack.
>
> A software RDMA stack might promote wider RDMA deployment,
> since when using the host TCP stack, it enables RDMA semantic
> independent of dedicated hardware. softiwarp peers with real
> RNICs (tested with Chelsio's T3 adapter).
>
> softiwarp is still work in progress and we are very thankful for any
> suggestions/comments/bug reports. Please advise how we should proceed
> to bring the stack further to your attention. Would it be useful to
> provide patches against the current stable kernel version or the next
> release candidate?
>
Hi Bernard,
So what I would recommend doing here to make things more appealing to
DaveM and other interested NetDev folks would be to clone a seperate
tree from the net-2.6.git or net-next-2.6.git repositories and include
the softiwarp/kernel.git code into a fresh 'in-kernel' clone tracking
the latest netdev code, and then keep git rebase'ing against DaveM's
last changes and update your local tree to the lastest netdev code.
Of course you will want to remove all of the 'out of tree' LINUX_VERSION
build macros and any other legacy bits to follow mainline kernel
convention for your 'in-kernel' softiwarp tree.
Best,
--nab
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: fix a lockdep splat
From: David Miller @ 2010-09-22 20:33 UTC (permalink / raw)
To: eric.dumazet; +Cc: penguin-kernel, linux-fsdevel, netdev
In-Reply-To: <1285184088.2380.18.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 22 Sep 2010 21:34:48 +0200
> [PATCH] net: fix a lockdep splat
>
> We have for each socket :
...
> This patch makes sure inet_csk_listen_stop() uses following lock order :
>
> write_lock_bh(&sk->sk_callback_lock)
> spin_lock(&sk->sk_slock)
> ...
> spin_unlock(&sk->sk_slock)
> write_unlock_bh(&sk->sk_callback_lock)
>
> Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
FWIW, this looks fine to me.
I'll apply it when we have positive testing feedback from
Tetsuo.
Thanks.
^ permalink raw reply
* [PATCH 2/2] siw: Add support for CRC32C offload instruction using libcrypto crc32c-intel
From: Nicholas A. Bellinger @ 2010-09-22 20:30 UTC (permalink / raw)
To: linux-kernel, netdev, linux-rdma, Bernard Metzler
Cc: David Miller, Matthew Wilcox, Andi Keen, Roland Dreier,
Nicholas Bellinger
From: Nicholas Bellinger <nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org>
This patch updates siw_create_qp() to check for the CONFIG_X86 + cpu_has_xmm4_2
dependent use of the CRC32C instruction offload using libcrypto crc32c-intel.ko.
This patch will by default use crc32c-intel when available, and fall back to the
legacy slicing by 1x libcrypto crc32c.ko code when the instruction offload is not
availabe.
Because of the ability to selectively use c_tx->crc_enabled and c_rx->crc_enabled,
this patch has to use a handful of less than appealing goto's in order to handle the
default case where the offload is enabled by default, the crc32c-intel module is
not available and we need to fall back to slicing by 1x crc32c.ko, or we need to
fail all together.
Note that this code has only been compile tested so far, but a similar patch
to LIO-Target (w/o the selectively use of TX/RX checksums) to use crc32c-intel.ko
instruction offload is available here:
http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=commitdiff;h=c92ef80235302a1f891f636691c928c3bb4e9ac1
Signed-off-by: Nicholas A. Bellinger <nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org>
---
softiwarp/siw_verbs.c | 37 ++++++++++++++++++++++++++++++++++++-
1 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/softiwarp/siw_verbs.c b/softiwarp/siw_verbs.c
index 27e2e5e..00ac03c 100644
--- a/softiwarp/siw_verbs.c
+++ b/softiwarp/siw_verbs.c
@@ -348,7 +348,7 @@ struct ib_qp *siw_create_qp(struct ib_pd *ofa_pd, struct ib_qp_init_attr *attrs,
struct siw_iwarp_rx *c_rx;
struct siw_uresp_create_qp uresp;
- int rv = 0;
+ int rv = 0, crc32c_offload = 1;
dprint(DBG_OBJ|DBG_CM, ": new QP on device %s\n",
ofa_dev->name);
@@ -460,6 +460,23 @@ struct ib_qp *siw_create_qp(struct ib_pd *ofa_pd, struct ib_qp_init_attr *attrs,
c_tx->crc_enabled = c_rx->crc_enabled = CONFIG_RDMA_SIW_CRC_ENFORCED;
if (c_tx->crc_enabled) {
+#ifdef CONFIG_X86
+ /*
+ * Check for the Nehalem optimized crc32c-intel instructions
+ * This is only currently available while running on bare-metal,
+ * and is not yet available with QEMU-KVM guests.
+ */
+ if (cpu_has_xmm4_2 && crc32c_offload) {
+ c_tx->mpa_crc_hd.tfm = crypto_alloc_hash("crc32c-intel",
+ 0, CRYPTO_ALG_ASYNC);
+ if (IS_ERR(c_tx->mpa_crc_hd.tfm)) {
+ crc32c_offload = 0;
+ goto check_legacy_tx;
+ }
+ goto check_rx;
+ }
+check_legacy_tx:
+#endif /* CONFIG_X86 */
c_tx->mpa_crc_hd.tfm =
crypto_alloc_hash("crc32c", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(c_tx->mpa_crc_hd.tfm)) {
@@ -469,7 +486,24 @@ struct ib_qp *siw_create_qp(struct ib_pd *ofa_pd, struct ib_qp_init_attr *attrs,
goto remove_qp;
}
}
+check_rx:
if (c_rx->crc_enabled) {
+#ifdef CONFIG_X86
+ /*
+ * Check for the Nehalem optimized crc32c-intel instructions
+ * This is only currently available while running on bare-metal,
+ * and is not yet available with QEMU-KVM guests.
+ */
+ if (cpu_has_xmm4_2 && crc32c_offload) {
+ c_rx->mpa_crc_hd.tfm = crypto_alloc_hash("crc32c-intel",
+ 0, CRYPTO_ALG_ASYNC);
+ if (IS_ERR(c_rx->mpa_crc_hd.tfm))
+ goto check_legacy_rx;
+
+ goto after_crc32c;
+ }
+check_legacy_rx:
+#endif /* CONFIG_X86 */
c_rx->mpa_crc_hd.tfm =
crypto_alloc_hash("crc32c", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(c_rx->mpa_crc_hd.tfm)) {
@@ -478,6 +512,7 @@ struct ib_qp *siw_create_qp(struct ib_pd *ofa_pd, struct ib_qp_init_attr *attrs,
goto remove_qp;
}
}
+after_crc32c:
atomic_set(&qp->tx_ctx.in_use, 0);
qp->ofa_qp.qp_num = QP_ID(qp);
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/2] siw: Fix ib_register_device() for > v2.6.34 kernels
From: Nicholas A. Bellinger @ 2010-09-22 20:30 UTC (permalink / raw)
To: linux-kernel, netdev, linux-rdma, Bernard Metzler
Cc: David Miller, Matthew Wilcox, Andi Keen, Roland Dreier,
Nicholas Bellinger
From: Nicholas Bellinger <nab@linux-iscsi.org>
This patch adds a LINUX_VERSION_CODE > v2.6.34 check inside of siw_main.c:siw_register_device()
around the use of ib_register_device(). In post v2.6.34 kernels this function accepts a second
parameter used a sysfs port callback described here:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9a6edb60ec10d86b1025a0cdad68fd89f1ddaf02
This patch currently sets this second parameter to NULL.
Signed-off-by: Nicholas A. Bellinger <nab@linux-iscsi.org>
---
softiwarp/siw_main.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/softiwarp/siw_main.c b/softiwarp/siw_main.c
index cacedea..c97adee 100644
--- a/softiwarp/siw_main.c
+++ b/softiwarp/siw_main.c
@@ -233,8 +233,11 @@ int siw_register_device(struct siw_dev *dev)
ibdev->iwcm->add_ref = siw_qp_get_ref;
ibdev->iwcm->rem_ref = siw_qp_put_ref;
ibdev->iwcm->get_qp = siw_get_ofaqp;
-
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 34)
+ rv = ib_register_device(ibdev, NULL);
+#else
rv = ib_register_device(ibdev);
+#endif
if (rv) {
dprint(DBG_DM|DBG_ON, "(dev=%s): "
"ib_register_device failed: rv=%d\n", ibdev->name, rv);
--
1.5.6.5
^ permalink raw reply related
* [PATCH 0/2] siw: Fix build failure for > v2.6.34 + add crc32c-intel.ko offload
From: Nicholas A. Bellinger @ 2010-09-22 20:30 UTC (permalink / raw)
To: linux-kernel, netdev, linux-rdma, Bernard Metzler
Cc: David Miller, Matthew Wilcox, Andi Keen, Roland Dreier,
Nicholas Bellinger
From: Nicholas Bellinger <nab@linux-iscsi.org>
Greetings Bernard and NetDev folks,
Attached are two patches for softiwarp/kernel.git, the first of which fixes a build
failure on > v2.6.34 kernels with ib_register_device(), and the second is the addition
of proper support for libcrypto crc32c-intel.ko using Nehalem SSE v4.2 instruction offload
which is an item that has been recently added into our LIO-Target v4.0.0-rc4 release
over on the linux-scsi list.
Please note that this code has only been compile tested so far, but I do plan to have
a deeper look at your teams work once I have a bit more free time on my hands.
Many great thanks for all of your efforts with IBM Software iWARP stack!
Signed-off-by: Nicholas A. Bellinger <nab@linux-iscsi.org>
Nicholas Bellinger (2):
siw: Fix ib_register_device() for > v2.6.34 kernels
siw: Add support for CRC32C offload instruction using libcrypto
crc32c-intel
softiwarp/siw_main.c | 5 ++++-
softiwarp/siw_verbs.c | 37 ++++++++++++++++++++++++++++++++++++-
2 files changed, 40 insertions(+), 2 deletions(-)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox