* Re: [PATCH] Use firmware provided index to register a network interface
From: Stephen Hemminger @ 2010-09-22 22:16 UTC (permalink / raw)
To: Tim Small
Cc: Narendra K, netdev, linux-hotplug, linux-pci, matt_domsch,
charles_rose, jordan_hargrave, vijay_nijhawan
In-Reply-To: <4C9A7E39.2020304@buttersideup.com>
On Wed, 22 Sep 2010 23:07:53 +0100
Tim Small <tim@buttersideup.com> wrote:
> Narendra K wrote:
> > Hello,
> >
> > Here is another approach to address the issue of "eth0 does not always
> > map to the Integrated NIC Port 1 as denoted on server chassis label".
> > For more details please refer to the thread -
> > http://marc.info/?l=linux-netdev&m=128163454631618&w=3.
> >
>
>
> Hi,
>
> Out of interest, that link says that doing it in usespace was rejected,
> but doesn't give any references... I'd be interested to know why this
> wasn't viable - since this seemed like the best fit at first glance -
> most people will never use this, so no need to grow their kernel size
> and complexity?
>
This proposal was to ad changes into every application that
knows about network names (iproute, iptables, snmp, quagga, openswan, ...)
to do aliasing at the application layer.
I rejected it as an unmanageable since it would require changes to so
many packages (many of which are more BSD focused). Also doing aliasing
would lead to security and other issues. For example, if you write a
iptables rule based on the "Embedded NIC 1" rule would it work and know
when the packet name lookup returned eth0, or what about device names
in the Quagga RIB, ...
^ permalink raw reply
* Re: [PATCH] net: fix a lockdep splat
From: Jarek Poplawski @ 2010-09-22 22:13 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tetsuo Handa, David Miller, linux-fsdevel, netdev
In-Reply-To: <1285184088.2380.18.camel@edumazet-laptop>
Eric Dumazet wrote:
> [PATCH] net: fix a lockdep splat
>
> We have for each socket :
>
> One spinlock (sk_slock.slock)
> One rwlock (sk_callback_lock)
>
> Possible scenarios are :
>
> (A) (this is used in net/sunrpc/xprtsock.c)
> read_lock(&sk->sk_callback_lock) (without blocking BH)
> <BH>
> spin_lock(&sk->sk_slock.slock);
> ...
> read_lock(&sk->sk_callback_lock);
> ...
>
>
> (B)
> write_lock_bh(&sk->sk_callback_lock)
> stuff
> write_unlock_bh(&sk->sk_callback_lock)
>
>
> (C)
> spin_lock_bh(&sk->sk_slock)
> ...
> write_lock_bh(&sk->sk_callback_lock)
> stuff
> write_unlock_bh(&sk->sk_callback_lock)
> spin_unlock_bh(&sk->sk_slock)
>
> This (C) case conflicts with (A) :
>
> CPU1 [A] CPU2 [C]
> read_lock(callback_lock)
> <BH> spin_lock_bh(slock)
> <wait to spin_lock(slock)>
> <wait to write_lock_bh(callback_lock)>
>
> We have one problematic (C) use case in inet_csk_listen_stop() :
>
> local_bh_disable();
> bh_lock_sock(child); // spin_lock_bh(&sk->sk_slock)
> WARN_ON(sock_owned_by_user(child));
> ...
> sock_orphan(child); // write_lock_bh(&sk->sk_callback_lock)
>
> lockdep is not happy with this, as reported by Tetsuo Handa
>
> 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)
IMHO this order conflicts with (A) too (but I'm not sure lockdep
tracks that):
CPU1 [A] CPU2 [C-reversed]
... write_lock_bh(callback_lock)
<BH>
spin_lock(slock)
<wait to spin_lock(slock)>
<wait to read_lock(callback_lock)>
My proposal is to BH protect read_lock(sk_callback_lock) everywhere (it's
done by netfilter in a few places already).
Jarek P.
^ permalink raw reply
* Re: [PATCH] Use firmware provided index to register a network interface
From: Tim Small @ 2010-09-22 22:07 UTC (permalink / raw)
To: Narendra K
Cc: netdev, linux-hotplug, linux-pci, matt_domsch, charles_rose,
jordan_hargrave, vijay_nijhawan
In-Reply-To: <20100922183137.GA7607@auslistsprd01.us.dell.com>
Narendra K wrote:
> Hello,
>
> Here is another approach to address the issue of "eth0 does not always
> map to the Integrated NIC Port 1 as denoted on server chassis label".
> For more details please refer to the thread -
> http://marc.info/?l=linux-netdev&m=128163454631618&w=3.
>
Hi,
Out of interest, that link says that doing it in usespace was rejected,
but doesn't give any references... I'd be interested to know why this
wasn't viable - since this seemed like the best fit at first glance -
most people will never use this, so no need to grow their kernel size
and complexity?
Cheers,
Tim.
^ permalink raw reply
* Re: [PATCH 2/2] siw: Add support for CRC32C offload instruction using libcrypto crc32c-intel
From: Jason Gunthorpe @ 2010-09-22 22:06 UTC (permalink / raw)
To: Nicholas A. Bellinger; +Cc: linux-kernel, netdev, linux-rdma, Bernard Metzler
In-Reply-To: <1285191511.1849.126.camel-Y1+j5t8j3WgjMeEPmliV8E/sVC8ogwMJ@public.gmane.org>
On Wed, Sep 22, 2010 at 02:38:31PM -0700, Nicholas A. Bellinger wrote:
> 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.
Well, it is what Andi said, everything is working fine but there is no
mechanism to autoload the accelerated crypto module. If you did
modprobe crc32c_intel prior to loading your driver it would
automatically get crc32c-intel when it asks for crc32c since it is
loaded and a higher priority.
So, the drivers are correct to just request crc32c .. The work around
to limited autoprobing is so trivial (modprob crc32_intel) I'm not
sure including extra autoprobing code in the drivers is worthwhile?
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: scheduling while atomic: br2684ctl (atm)
From: Paul E. McKenney @ 2010-09-22 21:54 UTC (permalink / raw)
To: Mikko Vinni
Cc: Karl Hiramoto, David S. Miller, Chas Williams - CONTRACTOR,
netdev, linux-kernel
In-Reply-To: <647401.39574.qm@web58406.mail.re3.yahoo.com>
On Wed, Sep 22, 2010 at 12:42:29AM -0700, Mikko Vinni wrote:
> Hi all,
>
> I get the following message apparently every time (on 2.6.36-rc4+ at least) when
> killing any old br2684ctl processes. "unregister_atmdevice_notifier" was added
> by
> 7313bb8f ("atm: propagate signal changes via notifier") so perhaps the
> unregister
> part was not tested properly for rcu interaction?
This complaint will happen when you call synchronize_rcu() while in some
context where it is illegal to block, for example, if irqs are disabled
or if a spinlock is held. I don't see commit 7313bb8f, but perhaps
unregister_atmdevice_notifier() is holding a spinlock across the call
to atomic_notifier_chain_unregister()?
Thanx, Paul
> So far I haven't noticed any ill effects from the message. Let me know if I
> should test something. Thanks.
>
> Mikko
>
>
> [29874.827053] PM: restore of devices complete after 3623.342 msecs
> [29874.827053] wlan0: Trigger new scan to find an IBSS to join
> [29875.020370] wlan0: Creating new IBSS network, BSSID 8a:4c:35:ef:eb:6b
> [29875.613701] wlan0: no IPv6 routers present
> [29876.027033] nas0: no IPv6 routers present
> [29876.831216] cxacru 3-1:1.0: receive of cm 0x90 failed (-104)
> [29876.844328] r8169 0000:09:00.0: PME# enabled
> [29876.878731] snapshot_ioctl: ioctl '4004330c' is deprecated and will be
> removed soon, update your suspend-to-disk utilities
> [29876.878741] Restarting tasks ... done.
> [29876.903718] PM: Basic memory bitmaps freed
> [29876.903718] video LNXVIDEO:01: Restoring backlight state
> [29879.703963] cxacru 3-1:1.0: found firmware cxacru-fw.bin
> [29879.708273] cxacru 3-1:1.0: loading firmware
> [29881.277932] cxacru 3-1:1.0: starting device
> [29882.346357] cxacru0: ADSL USB MODEM (usb-0000:00:12.0-1) 00:04:ed:09:1e:5a
> [29882.362575] ATM dev 0: ADSL state: running
> [29882.362593] ATM dev 0: ADSL line: down
> [29882.580484] BUG: scheduling while atomic: br2684ctl/28543/0x00000002
> [29882.580498] Modules linked in: nls_cp437 vfat fat usb_storage cpufreq_stats
> iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack
> nf_defrag_ipv4 ip_tables x_tables br2684 ipv6 sco bnep l2cap bluetooth ext2
> cxacru arc4 ecb usbatm atm uvcvideo videodev v4l1_compat v4l2_compat_ioctl32
> snd_seq_dummy snd_seq_oss snd_hda_codec_atihdmi snd_seq_midi_event
> snd_hda_codec_idt snd_seq snd_seq_device ath5k snd_hda_intel snd_pcm_oss
> snd_hda_codec snd_mixer_oss mac80211 joydev ath snd_hwdep snd_pcm video ohci_hcd
> hp_wmi output snd_timer cfg80211 ehci_hcd hp_accel lis3lv02d battery rfkill
> input_polldev snd wmi thermal ohci1394 psmouse jmb38x_ms pcspkr ac edac_core
> i2c_piix4 sg soundcore usbcore snd_page_alloc button serio_raw evdev memstick
> powernow_k8 led_class r8169 processor k10temp mii ieee1394 mperf rtc_cmos
> rtc_core rtc_lib ext4 mbcache jbd2 crc16 sr_mod cdrom sd_mod ahci libahci
> pata_atiixp pata_acpi libata scsi_mod radeon ttm drm_kms_helper drm i2c_algo_bit
> i2c_core [last unloaded: mmc_core]
> [29882.580796] Pid: 28543, comm: br2684ctl Not tainted
> 2.6.36-rc4-CUST-00214-g2422084 #49
> [29882.580808] Call Trace:
> [29882.580845] [<ffffffff8103cfd1>] __schedule_bug+0x61/0x70
> [29882.580865] [<ffffffff8131202e>] schedule+0x8de/0xa90
> [29882.580882] [<ffffffff81312745>] schedule_timeout+0x215/0x350
> [29882.580900] [<ffffffff8127f470>] ? flush_backlog+0x0/0x120
> [29882.580924] [<ffffffff81080722>] ? smp_call_function_single+0x172/0x190
> [29882.580937] [<ffffffff8127f470>] ? flush_backlog+0x0/0x120
> [29882.580951] [<ffffffff81311610>] wait_for_common+0xc0/0x150
> [29882.580968] [<ffffffff81046050>] ? default_wake_function+0x0/0x10
> [29882.580985] [<ffffffff81311748>] wait_for_completion+0x18/0x20
> [29882.581004] [<ffffffff810a95d6>] synchronize_rcu+0x46/0x50
> [29882.581025] [<ffffffff810683a0>] ? wakeme_after_rcu+0x0/0x10
> [29882.581051] [<ffffffff81070eb0>] atomic_notifier_chain_unregister+0x60/0x80
> [29882.581083] [<ffffffffa050ddc3>] unregister_atmdevice_notifier+0x13/0x20
> [atm]
> [29882.581102] [<ffffffffa05d588d>] br2684_push+0x2bd/0x320 [br2684]
> [29882.581124] [<ffffffffa050e2f6>] vcc_release+0x76/0x130 [atm]
> [29882.581142] [<ffffffff8126ef94>] sock_release+0x24/0x90
> [29882.581155] [<ffffffff8126f012>] sock_close+0x12/0x30
> [29882.581174] [<ffffffff8110c5c5>] fput+0xd5/0x230
> [29882.581188] [<ffffffff81108edb>] filp_close+0x5b/0x80
> [29882.581207] [<ffffffff8104ee67>] put_files_struct+0x97/0x100
> [29882.581221] [<ffffffff8104ef8d>] exit_files+0x4d/0x60
> [29882.581234] [<ffffffff8104f118>] do_exit+0x178/0x810
> [29882.581256] [<ffffffff8100cc9c>] ? fpu_finit+0x1c/0x30
> [29882.581270] [<ffffffff8104fa3f>] do_group_exit+0x4f/0xb0
> [29882.581283] [<ffffffff8104fab2>] sys_exit_group+0x12/0x20
> [29882.581300] [<ffffffff81002e82>] system_call_fastpath+0x16/0x1b
> [29883.353415] ATM dev 0: ADSL line: initializing
> [29884.359446] ATM dev 0: ADSL line: down
> [29887.862669] ata3.00: configured for UDMA/100
> [29887.862688] ata3: EH complete
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: igmp: Staggered igmp report intervals for unsolicited igmp reports
From: Jason Gunthorpe @ 2010-09-22 21:50 UTC (permalink / raw)
To: Christoph Lameter
Cc: David Stevens, David S. Miller, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Bob Arendt
In-Reply-To: <alpine.DEB.2.00.1009221448460.32661-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
On Wed, Sep 22, 2010 at 02:58:15PM -0500, Christoph Lameter wrote:
> > packets if it isn't ready quickly? A querier is what makes these
> > reliable, but for the start-up in particular, I think it'd be better
> > to not initiate the send on devices that have this problem until the
> > device is actually ready to send-- why not put the delay in the device
> > driver on initialization?
>
> The device is ready. Its just the multicast group that has not been
> established yet.
In IB when the SA replies to a group join the group should be ready,
prior to that the device can't send into the group because it has no
MLID for the group.. If you have a MLID then the group is working.
Is the issue you are dropping IGMP packets because the 224.0.0.2 join
hasn't finished? Ideally you'd wait for the SA to reply before sending
a IGMP, but a simpler solution might just be to use the broadcast MLID
for packets addressed to a MGID that has not yet got a MLID. This
would bebe similar to the ethernet behaviour of flooding.
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: Fw: rcu warning
From: Andrew Morton @ 2010-09-22 21:47 UTC (permalink / raw)
To: paulmck; +Cc: eric.dumazet, netdev
In-Reply-To: <20100922214438.GN2435@linux.vnet.ibm.com>
On Wed, 22 Sep 2010 14:44:38 -0700
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> 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.)
current linux-next.
^ permalink raw reply
* 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
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