* RE: [PATCH NEXT 12/12] netxen: update version to 4.0.41
From: Dhananjay Phadke @ 2009-07-27 19:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20090727.105403.202219074.davem@davemloft.net>
Ok, the idea for module params was to set global defaults
(configured in modprobe.conf) vs. per interface ethtool calls.
The ethtool support is anyway added by # 12 patch.
Is it not good to have both options available?
I will sync up my tree and see if the merge is functionally
correct.
Thanks,
Dhananjay
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Monday, July 27, 2009 10:54
> To: Dhananjay Phadke
> Cc: netdev@vger.kernel.org
> Subject: Re: [PATCH NEXT 12/12] netxen: update version to 4.0.41
>
>
> Ok, in order to make this build I'm going to have to insert
> some parts of patch #6 which I rejected because that adds
> ring size defaults/max/etc. defines which get used by later
> patches.
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.392 / Virus Database: 270.13.25/2256 - Release
> Date: 07/27/09 05:58:00
>
^ permalink raw reply
* Re: [PATCH] xfrm: export xfrm garbage collector thresholds via sysctl
From: Neil Horman @ 2009-07-27 19:36 UTC (permalink / raw)
To: David Miller
Cc: netdev, joe, herbert, kuznet, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <20090727.113755.260927092.davem@davemloft.net>
On Mon, Jul 27, 2009 at 11:37:55AM -0700, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Mon, 27 Jul 2009 14:22:46 -0400
>
> > Export garbage collector thresholds for xfrm[4|6]_dst_ops
> >
> > Had a problem reported to me recently in which a high volume of ipsec
> > connections on a system began reporting ENOBUFS for new connections eventually.
> > It seemed that after about 2000 connections we started being unable to create
> > more. A quick look revealed that the xfrm code used a dst_ops structure that
> > limited the gc_thresh value to 1024, and alaways dropped route cache entries
> > after 2x the gc_thresh. It seems the most direct solution is to export the
> > gc_thresh values in the xfrm[4|6] dst_ops as sysctls, like the main routing
> > table does, so that higher volumes of connections can be supported. This patch
> > has been tested and allows the reporter to increase their ipsec connection
> > volume successfully.
> >
> > Reported-by: Joe Nall <joe@nall.com>
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>
> Applied, but this suggests that either:
>
Thanks!
> 1) we pick a horrible default
>
> 2) our IPSEC machinery holds onto dst entries too tightly and that's
> the true cause of this problem
>
> I'd like to ask that you investigate this, because with defaults
> we should be able to handle IPSEC loads as high as the routing
> loads we could handle.
>
I'll gladly look into this further. Compared to the main routing table, the
ipsec default selection is pretty bad. Its statcially set despite the size of
the larger routing table. Looking at the garbage collection algorithm, we do
keep a pretty tight leash on freeing entries, but I think its warrented. We
create 1 dst_entry for each open socket on an ipsec tunnel, and don't release it
until its __refcnt drops to zero. I think that makes sense, since it means
we only keep cache entries for active connections, and clean them up as soon as
they close (e.g. I don't really see the advantage to unhashing a xfrm cache
entry only to recreate it on the next packet sent). I think the most sensible
first step is to dynamically choose a gc threshold based on the size of memory
or the main routing table. I'll write this up and post later this week after I
do some testing. Thanks!
Neil
> Thanks.
>
^ permalink raw reply
* Re: [PATCH NEXT 12/12] netxen: update version to 4.0.41
From: David Miller @ 2009-07-27 19:38 UTC (permalink / raw)
To: dhananjay.phadke; +Cc: netdev
In-Reply-To: <7608421F3572AB4292BB2532AE89D56581877E22A4@AVEXMB1.qlogic.org>
From: Dhananjay Phadke <dhananjay.phadke@qlogic.com>
Date: Mon, 27 Jul 2009 12:26:58 -0700
> Ok, the idea for module params was to set global defaults
> (configured in modprobe.conf) vs. per interface ethtool calls.
> The ethtool support is anyway added by # 12 patch.
>
> Is it not good to have both options available?
No, it is not good.
With module parameters we:
1) duplicate functionality
2) every device driver will name the module parms differently,
therefore the interface for the user is different for every device
type
We discuss this all the time, and this is a pretty deep rooted
belief and requirement for all network drivers.
^ permalink raw reply
* Re: [PATCH] xfrm: export xfrm garbage collector thresholds via sysctl
From: David Miller @ 2009-07-27 19:40 UTC (permalink / raw)
To: nhorman; +Cc: netdev, joe, herbert, kuznet, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <20090727193625.GD15823@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Mon, 27 Jul 2009 15:36:25 -0400
> I think that makes sense, since it means we only keep cache entries
> for active connections, and clean them up as soon as they close
> (e.g. I don't really see the advantage to unhashing a xfrm cache
> entry only to recreate it on the next packet sent).
How is this related to the user's problem?
My impression was that they were forwarding IPSEC traffic when
running up against these limits, and that has no socket based
assosciation at all.
Making the XFRM GC limits get computed similarly to how the
ipv4/ipv6 one's do probably makes sense.
^ permalink raw reply
* Re: [PATCH] xfrm: export xfrm garbage collector thresholds via sysctl
From: Joe Nall @ 2009-07-27 20:02 UTC (permalink / raw)
To: David Miller
Cc: nhorman, netdev, herbert, kuznet, pekkas, jmorris, yoshfuji,
kaber
In-Reply-To: <20090727.124011.05728493.davem@davemloft.net>
On Jul 27, 2009, at 2:40 PM, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Mon, 27 Jul 2009 15:36:25 -0400
>
>> I think that makes sense, since it means we only keep cache entries
>> for active connections, and clean them up as soon as they close
>> (e.g. I don't really see the advantage to unhashing a xfrm cache
>> entry only to recreate it on the next packet sent).
>
> How is this related to the user's problem?
>
> My impression was that they were forwarding IPSEC traffic when
> running up against these limits, and that has no socket based
> assosciation at all.
>
> Making the XFRM GC limits get computed similarly to how the
> ipv4/ipv6 one's do probably makes sense.
The problem was seen serving TCP connections over IPSec when the
server (a 24 core machine w 32GB RAM) and the IPSec host were the same
(transport not tunnel).
The problem was originally identified in an MLS ipsec thin client
stress test with 25 clients and 200+ windows per client.
We then duplicated the issue with single level xclocks on the same
hardware.
I then duplicated the problem with two bone stock (not MLS) F10 (and
later F11) boxes running ab (apache benchmark tool) with 10k requests
over 2k concurrent connections. See https://bugzilla.redhat.com/show_bug.cgi?id=503124
With the gc_thresh raised to 8k, my ab test passes with 5k+
connections and 100k requests. Our test guys ran 11 workstations with
about 2200 concurrent X connections over the weekend and I'm hoping
for some MLS results before we lose the test suite on Wednesday.
joe
^ permalink raw reply
* Re: [PATCH] xfrm: export xfrm garbage collector thresholds via sysctl
From: David Miller @ 2009-07-27 20:10 UTC (permalink / raw)
To: joe; +Cc: nhorman, netdev, herbert, kuznet, pekkas, jmorris, yoshfuji,
kaber
In-Reply-To: <7E46FEB5-E422-45B2-9D68-010DD7C23B78@nall.com>
From: Joe Nall <joe@nall.com>
Date: Mon, 27 Jul 2009 15:02:20 -0500
> The problem was seen serving TCP connections over IPSec when the
> server (a 24 core machine w 32GB RAM) and the IPSec host were the same
> (transport not tunnel).
Aha, thanks for the clarification, that makes a lot more sense.
^ permalink raw reply
* [GIT]: Networking
From: David Miller @ 2009-07-27 20:35 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Enable smc91x to work on Nomadik evaluation ARM borads.
From Alessandro Rubini
2) Build fix, KS8851 needs MII, from Alexander Beregalov
3) WoL got busted in ixgbe, fix from Andy Gospodarek.
4) Fixed-link support in fs_enet/gianfar/ucc_geth/of-mdio was
broken unintentionally, fix from Anton Vorontsov.
5) irda memcpys into a spinlock, forgets to initialize it,
lockdep gets angry, fix from Deepak Saxena
6) ixgbe counts UDP checksum errors that aren't due to an errata,
fix from Don Skidmore
7) Broadcom CNIC driver doesn't handle ISCSI_KEVENT_IF_DOWN messages
properly, fix from Michael Chan.
8) Turn WoL on by default in skge if supported, from Rafael J. Wysocki.
9) ROSE protocol uses static buffer for computing procfs output
strings, which doesn't work very well on SMP, fix from Ralf Baechle
10) When bridging's br_add_if fails, we don't release kobjects properly,
fix from Xiaotian Feng
11) Fix WoL for 8169 chips, from François Romieu.
12) Several out-of-bounds array access fixes from Roel Kluin
(eepro, fealnx, at1700, tokenring)
13) Netxen driver fix for suspend/resume, wasn't resetting the
consumer ring pointer properly. Fix from Dhananjay Phadke.
14) Wireless fixes from John Linville and the wireless crew.
Please pull, thanks a lot!
The following changes since commit e00b95debb9a0f023b61abcd4b1e74f687276b47:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../bp/bp
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Ajit Khaparde (1):
be2net: Bug fix in the non-lro path. Size of received packet was not updated in statistics properly.
Alan Jenkins (3):
rfkill: fix rfkill_set_states() to set the hw state
rfkill: remove too-strict __must_check
acer-wmi: fix rfkill conversion
Alessandro Rubini (1):
smc91x.h: add config for Nomadik evaluation kit
Alexander Beregalov (1):
net: KS8851 needs to depend on MII
Andy Gospodarek (1):
ixgbe: remove unnecessary call to device_init_wakeup
Andy Whitcroft (1):
rt2x00: Fix chipset detection for rt2500usb
Anton Vorontsov (4):
of/mdio: Add support function for Ethernet fixed-link property
fs_enet: Revive fixed link support
gianfar: Revive fixed link support
ucc_geth: Revive fixed link support
Bob Copeland (1):
ath5k: temporarily disable crypto for AP mode
Christian Lamparter (1):
cfg80211: double free in __cfg80211_scan_done
Dan Carpenter (1):
p54spi: fix potential null deref in p54spi.c
David S. Miller (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Deepak Saxena (1):
net: irda: init spinlock after memcpy
Dhananjay Phadke (1):
netxen: reset ring consumer during cleanup
Don Skidmore (1):
ixgbe: fix for 82599 errata marking UDP checksum errors
Javier Cardona (1):
mac80211: use correct address for mesh Path Error
Johannes Berg (4):
mac80211: disable mesh
rfkill: allow toggling soft state in sysfs again
mac80211_hwsim: fix unregistration
mac80211_hwsim: fix use after free
Larry Finger (1):
rtl8187: Fix for kernel oops when unloading with LEDs enabled
Lucy Liu (1):
ixgbe: Don't priority tag control frames in DCB mode
Luis R. Rodriguez (2):
ath9k: Tune ANI function processing on AP mode during ANI reset
ath: add support for special 0x8000 regulatory domain
Marek Vasut (1):
libertas: Fix problem with broken V4 firmware on CF8381
Mark Ware (1):
net: Rework mdio-ofgpio driver to use of_mdio infrastructure
Michael Chan (1):
cnic: Fix ISCSI_KEVENT_IF_DOWN message handling.
Niko Jokinen (1):
nl80211: Memory leak fixed
Pavel Roskin (1):
mac80211: fix injection in monitor mode
Rafael J. Wysocki (1):
skge: Enable WoL by default if supported
Ralf Baechle (1):
NET: ROSE: Don't use static buffer.
Reinette Chatre (2):
iwlwifi: only show active power level via sysfs
iwlwifi: only update byte count table during aggregation
Roel Kluin (1):
eepro: Read buffer overflow
Uwe Kleine-König (1):
register at91_ether using platform_driver_probe
Xiaotian Feng (1):
net/bridge: use kobject_put to release kobject in br_add_if error path
Yi Zou (1):
ixgbe: Enable FCoE offload when DCB is enabled for 82599
Zhu Yi (1):
iwmc3200wifi: fix NULL pointer dereference in iwm_if_free
françois romieu (1):
r8169: WakeOnLan fix for the 8168
roel kluin (3):
fealnx: Write outside array bounds
at1700: Read buffer overflow
tokenring: Read buffer overflow
drivers/net/Kconfig | 1 +
drivers/net/arm/at91_ether.c | 3 +-
drivers/net/at1700.c | 2 +-
drivers/net/benet/be_main.c | 8 ++--
drivers/net/cnic.c | 23 +++++++-
drivers/net/eepro.c | 2 +-
drivers/net/fealnx.c | 3 +-
drivers/net/fs_enet/fs_enet-main.c | 20 ++++----
drivers/net/gianfar.c | 24 +++------
drivers/net/ixgbe/ixgbe.h | 1 +
drivers/net/ixgbe/ixgbe_dcb_nl.c | 24 ++++++++
drivers/net/ixgbe/ixgbe_main.c | 52 +++++++++++-------
drivers/net/netxen/netxen_nic_init.c | 7 +++
drivers/net/phy/mdio-gpio.c | 77 ++++++++++++--------------
drivers/net/r8169.c | 13 ++++-
drivers/net/skge.c | 4 +-
drivers/net/smc91x.h | 3 +-
drivers/net/tokenring/ibmtr.c | 2 +-
drivers/net/ucc_geth.c | 23 +++------
drivers/net/wireless/ath/ath5k/base.c | 3 +
drivers/net/wireless/ath/ath9k/ani.c | 12 ++++
drivers/net/wireless/ath/regd.c | 17 ++++++
drivers/net/wireless/iwlwifi/iwl-agn.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-tx.c | 3 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 4 +-
drivers/net/wireless/iwmc3200wifi/netdev.c | 2 +-
drivers/net/wireless/libertas/cmd.c | 8 +++-
drivers/net/wireless/libertas/defs.h | 2 +
drivers/net/wireless/mac80211_hwsim.c | 6 +-
drivers/net/wireless/p54/p54spi.c | 2 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 4 +-
drivers/net/wireless/rtl818x/rtl8187_leds.c | 3 +-
drivers/of/of_mdio.c | 42 +++++++++++++++
drivers/platform/x86/acer-wmi.c | 2 +-
include/linux/of_mdio.h | 3 +
include/linux/rfkill.h | 2 +-
include/net/rose.h | 2 +-
net/bridge/br_if.c | 2 +-
net/irda/irttp.c | 1 +
net/mac80211/Kconfig | 1 +
net/mac80211/mesh_pathtbl.c | 11 +++-
net/mac80211/tx.c | 2 +-
net/rfkill/core.c | 31 ++++++++---
net/rose/af_rose.c | 18 +++----
net/rose/rose_route.c | 23 ++++----
net/wireless/nl80211.c | 5 +-
net/wireless/scan.c | 3 +-
47 files changed, 336 insertions(+), 174 deletions(-)
^ permalink raw reply
* Re: [PATCH] net: Keep interface binding when sending packets with ipi_ifindex = 0
From: Andrew Morton @ 2009-07-27 21:44 UTC (permalink / raw)
To: Chia-chi Yeh; +Cc: linux-kernel, netdev
In-Reply-To: <6c039e090907231439t1def08a4n10978733bee55bec@mail.gmail.com>
(cc netdev)
On Thu, 23 Jul 2009 14:39:28 -0700
Chia-chi Yeh (_________) <chiachi@android.com> wrote:
> In IPv4, sending a packet with ipi_ifindex = 0 via an interface-bound
> socket will unbind the packet to that interface. This behavior is
> different from IPv6 which treats ipi6_ifindex = 0 as unspecified.
> Furthermore, IPv6 does not allow sending packets to other interface
> than the bound one, but I am not sure if it is necessary in IPv4. The
> following patch keeps the interface binding when ipi_ifindex = 0.
>
> Thanks,
> Chia-chi
>
> --- a/net/ipv4/ip_sockglue.c 2009-07-24 04:50:45.000000000 +0800
> +++ b/net/ipv4/ip_sockglue.c 2009-07-24 04:51:09.000000000 +0800
> @@ -213,7 +213,8 @@
> if (cmsg->cmsg_len != CMSG_LEN(sizeof(struct in_pktinfo)))
> return -EINVAL;
> info = (struct in_pktinfo *)CMSG_DATA(cmsg);
> - ipc->oif = info->ipi_ifindex;
> + if (info->ipi_ifindex)
> + ipc->oif = info->ipi_ifindex;
> ipc->addr = info->ipi_spec_dst.s_addr;
> break;
> }
^ permalink raw reply
* Re: [PATCH NEXT 12/12] netxen: update version to 4.0.41
From: Dhananjay Phadke @ 2009-07-27 21:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20090727.123807.268367807.davem@davemloft.net>
Agreed that it duplicates work in individual drivers,
and the naming style followed by different vendors.
But the problem is ethtool can work only after driver
has successfully initialized interfaces. Otherwise,
ethtool gets no chance to tune up/down.
The driver defaults are for tuned for typical use cases.
On some frugal systems with lower amount of RAM, the
driver bails out failing to allocate enough ring space
or rx buffers [especially for 32-bit kernels]. This is
also a problem for multi-function (more than one PCI
function per physical port) mode, where number of
interfaces and hence the memory consumption gets
multiplied. For these cases something that can set
the bar before device initialization, is quite helpful.
Thanks,
Dhananjay
David Miller wrote:
> No, it is not good.
>
> With module parameters we:
>
> 1) duplicate functionality
>
> 2) every device driver will name the module parms differently,
> therefore the interface for the user is different for every device
> type
>
> We discuss this all the time, and this is a pretty deep rooted
> belief and requirement for all network drivers.
^ permalink raw reply
* Re: r8169 (+others ?) and note_interrupt performance hit on 2.6.30.x
From: Jarek Poplawski @ 2009-07-27 21:52 UTC (permalink / raw)
To: Michal Soltys; +Cc: Francois Romieu, netdev
In-Reply-To: <4A6CA3EF.7080909@ziu.info>
Michal Soltys wrote, On 07/26/2009 08:43 PM:
...
> Anwyay, not sure if this is useful, so if there is anything better
> I could do, just push me in the right direction.
Short test of 2.6.29? (Unless you prefer a bisection...)
Jarek P.
^ permalink raw reply
* Re: ixgbe: panic in ixgbe_clean_rx_irq()
From: Todd Merritt @ 2009-07-27 21:50 UTC (permalink / raw)
To: netdev
In-Reply-To: <Pine.WNT.4.64.0907241142370.2084@ppwaskie-MOBL2.amr.corp.intel.com>
Waskiewicz Jr, Peter P <peter.p.waskiewicz.jr <at> intel.com> writes:
>
> On Fri, 24 Jul 2009, Jesper Dangaard Brouer wrote:
>
> > On Thu, 2009-07-23 at 17:21 +0200, Jesper Dangaard Brouer wrote:
> > > I'm going to run a test with a no-preempt kernel over night...
> >
> > The no-preempt kernel has been stable for 17 hours, while running a four
> > times 10GbE pktgen load test (using 1024 bytes packets).
> >
> > Kernel git version (git describe):
> > v2.6.31-rc1-932-g8e321c4
> >
> > Git ("git log e594e96..8e321c4 drivers/net/ixgbe") reports not changes
> > to the ixgbe driver between these two kernel versions.
>
> Thanks for the additional info Jesper. This is definately a good data
> point. I'm not sure where to go with the preemption debugging at this
> point with our driver under heavy load. We're still trying to repro here.
> I'll keep digging around though in the meantime.
>
> This is the second preemption-induced bug from ixgbe we've had reported in
> a few days. Eek!
>
We're getting a panic in the same function with the stable version of the ixgbe
driver 2.0.38.2-1 on redhat 5 kernel-2.6.18-128.1.10.el5. Is there a dev
release of the driver that might have a fix in it ?
Thanks,
Todd
^ permalink raw reply
* Re: ixgbe: panic in ixgbe_clean_rx_irq()
From: Waskiewicz Jr, Peter P @ 2009-07-27 22:31 UTC (permalink / raw)
To: Todd Merritt; +Cc: netdev@vger.kernel.org
In-Reply-To: <loom.20090727T214746-75@post.gmane.org>
On Mon, 27 Jul 2009, Todd Merritt wrote:
> We're getting a panic in the same function with the stable version of the ixgbe
> driver 2.0.38.2-1 on redhat 5 kernel-2.6.18-128.1.10.el5. Is there a dev
> release of the driver that might have a fix in it ?
Are you also running with preemption enabled? We're having a very tough
time reproducing this bug in our lab, so no, we don't have any fix for it
yet.
-PJ
^ permalink raw reply
* Re: Kernel oops on setting sky2 interfaces down
From: Stephen Hemminger @ 2009-07-27 22:35 UTC (permalink / raw)
To: Rene Mayrhofer; +Cc: netdev, Richard Leitner
In-Reply-To: <4A6D8975.4050000@gibraltar.at>
Does this help?
--- a/drivers/net/sky2.c 2009-07-27 15:28:27.653757064 -0700
+++ b/drivers/net/sky2.c 2009-07-27 15:34:24.358730966 -0700
@@ -2763,6 +2763,11 @@ static int sky2_poll(struct napi_struct
int work_done = 0;
u16 idx;
+ if (unlikely(status == ~0)) {
+ dev_info(&hw->pdev->dev, "device status error\n");
+ goto clear_napi;
+ }
+
if (unlikely(status & Y2_IS_ERROR))
sky2_err_intr(hw, status);
@@ -2779,6 +2784,7 @@ static int sky2_poll(struct napi_struct
goto done;
}
+clear_napi:
napi_complete(napi);
sky2_read32(hw, B0_Y2_SP_LISR);
done:
^ permalink raw reply
* ESP - Differing Lengths Passed from ESP
From: Vlad Dogaru @ 2009-07-27 23:10 UTC (permalink / raw)
To: netdev
Hello,
Is there any reason that, in an ablkcipher_request, fields nbytes and
src->length differ by 12 bytes? I'm asking this on netdev since the data
comes from ESP, apologies if this is inappropriate.
Thanks,
Vlad
^ permalink raw reply
* Re: [PATCH v2] IPVS: logging sizeof(struct ip_vs_conn) on startup
From: Simon Horman @ 2009-07-28 0:19 UTC (permalink / raw)
To: David Miller
Cc: heder, netdev, eric.dumazet, lvs-users, malcolm, linux-kernel
In-Reply-To: <20090727.114845.177925839.davem@davemloft.net>
On Mon, Jul 27, 2009 at 11:48:45AM -0700, David Miller wrote:
> From: Hannes Eder <heder@google.com>
> Date: Mon, 27 Jul 2009 15:13:57 +0200
>
> > No more guessing, how much memory used by IPVS for a connection.
> >
> > [ The number printed is a lower bound, as ip_vs_conn_cache uses
> > SLAB_HWCACHE_ALIGN. ]
> >
> > Signed-off-by: Hannes Eder <heder@google.com>
> > Signed-off-by: Simon Horman <horms@verge.net.au>
>
> Who needs to know this? A developer?
>
> They can run tools such as 'pahole' et al. to fish out this
> information even when only a kernel binary is available.
>
> For the user, it's just noise.
>
> I'm not applying this, sorry.
Surprisingly its a very common question amongst users,
because they want to know how much memory they need.
It is of course all a bit silly, because the amount of
memory used by the connection table is usually very small,
but people still ask.
^ permalink raw reply
* Re: [PATCH] ip: fix logic of reverse path filter sysctl
From: David Miller @ 2009-07-28 1:40 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20090724123005.35450325@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 24 Jul 2009 12:30:05 -0700
> Even though reverse path filter was changed from simple boolean to trinary control,
> the loose mode only works if both all and device are configured because of
> this logic error.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Good catch, applied, thanks Stephen!
^ permalink raw reply
* Re: [RFC] [PATCH] Don't run __qdisc_run() on a stopped TX queue
From: David Miller @ 2009-07-28 2:28 UTC (permalink / raw)
To: herbert; +Cc: krkumar2, jarkao2, netdev
In-Reply-To: <20090725032436.GA30741@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 25 Jul 2009 11:24:36 +0800
> Dave, remember our discussion about the benefits of using multiqueue
> TX just for the sake of enarlging the TX queues? How about just
> going back to using a single queue for non-default qdiscs (at
> least until such a time when non-default qdiscs start doing
> multiple queues internally)?
>
> Yes it would mean potentially smaller queues for those non-default
> qdisc users, but they're usually the same people who want the
> hardware to queue as little as possible in order to enforce whatever
> it is that their qdisc is designed to enforce.
There is a locking benefit even for non-default qdiscs.
Instead of two choke points (qdisc lock and queue lock) there
is now only one (qdisc lock) and consdiering the cost of
things like setting up IOMMU mappings and hitting chip
registers the qdisc lock is the shortest held of the two.
So going to one queue would be a serious regression.
^ permalink raw reply
* Re: net-next-2.6 phonet causes build error
From: David Miller @ 2009-07-28 2:31 UTC (permalink / raw)
To: dada1; +Cc: remi.denis-courmont, eric.dumazet, netdev
In-Reply-To: <4A6D60B4.1070601@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Mon, 27 Jul 2009 10:09:24 +0200
> I currently use gcc-3.4.6, and current net-next-2.6 doesnt compile
> for me (but linux-2.6 does compile properly so I just know this is
> already fixed upstream)
Eric, just FYI, I am not going to merge Linus's tree into
net-2.6 (and therefore not into net-next-2.6 either) unless
there is some conflict to resolve.
So if you need this build fix, please integrate it locally
by whatever means works best for you.
^ permalink raw reply
* Re: [RFC] [PATCH] Don't run __qdisc_run() on a stopped TX queue
From: Herbert Xu @ 2009-07-28 2:48 UTC (permalink / raw)
To: David Miller; +Cc: krkumar2, jarkao2, netdev
In-Reply-To: <20090727.192844.163233275.davem@davemloft.net>
On Mon, Jul 27, 2009 at 07:28:44PM -0700, David Miller wrote:
>
> There is a locking benefit even for non-default qdiscs.
>
> Instead of two choke points (qdisc lock and queue lock) there
> is now only one (qdisc lock) and consdiering the cost of
> things like setting up IOMMU mappings and hitting chip
> registers the qdisc lock is the shortest held of the two.
But only one CPU can process a given qdisc at one time so I don't
see why there is a second choke point if you use a single queue
with a non-default qdisc.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] pxaficp-ir - remove incorrect net_device_ops
From: Eric Miao @ 2009-07-28 3:01 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Russell King - ARM Linux, samuel, netdev,
Alexander Beregalov
In-Reply-To: <200907240257.10906.marek.vasut@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]
Marek Vasut wrote:
> Hi!
>
> This patch fixes broken pxaficp-ir. The problem was in incorrect
> net_device_ops being specified which prevented the driver from
> operating. The symptoms were:
> - failing ifconfig for IrLAN, resulting in
> SIOCSIFFLAGS: Cannot assign requested address
> - irattach working for IrCOMM, but the port stayed disabled
>
> Moreover this patch corrects missing sysfs device link.
>
> btw. guys, be honest, when did you last tested pxaficp-ir on real hardware? ;-)
>
Well, this seems to be brought by the net_device_ops change, which seems
to happen silently without any of us being notified.
OK, netdev and Alex are copied, so that we can look into this issue a bit
deeper:
1. it looks to me that SIOCSIFFLAGS actually returned -EADDRNOTAVAIL, which
is likely caused by eth_validate_addr, the default eth_addr comes with
irda should be "00:00:00:00:00:00" if not explicitly specified (kzalloc),
and this should be the problem, solution ? Either give a valid address
to the irda net_device or remove this 'ndo_validate_addr'. And which is
a correct fix will impact on the .ndo_set_mac_address
2. '.ndo_change_mtu' ? It looks to me that Irda device doesn't care too much
about the MTU, eth_change_mtu is supposed to work just fine and not to
cause any side effects, and may just benefit later irda device drivers if
there is a weird device happens to care about MTU
- eric
Marek's original patch in attachment.
[-- Attachment #2: 0001-pxaficp-ir-remove-incorrect-net_device_ops.patch --]
[-- Type: text/x-diff, Size: 1520 bytes --]
>From 28b229f0f3f807d775a7e70b96c018eef935a24a Mon Sep 17 00:00:00 2001
From: Marek Vasut <marek.vasut@gmail.com>
Date: Fri, 24 Jul 2009 02:44:02 +0200
Subject: [PATCH] pxaficp-ir - remove incorrect net_device_ops
This patch fixes broken pxaficp-ir. The problem was in incorrect
net_device_ops being specified which prevented the driver from
operating. The symptoms were:
- failing ifconfig for IrLAN, resulting in
SIOCSIFFLAGS: Cannot assign requested address
- irattach working for IrCOMM, but the port stayed disabled
Moreover this patch corrects missing sysfs device link.
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
---
drivers/net/irda/pxaficp_ir.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/irda/pxaficp_ir.c b/drivers/net/irda/pxaficp_ir.c
index 4edbdbe..f5b7d83 100644
--- a/drivers/net/irda/pxaficp_ir.c
+++ b/drivers/net/irda/pxaficp_ir.c
@@ -820,9 +820,6 @@ static const struct net_device_ops pxa_irda_netdev_ops = {
.ndo_stop = pxa_irda_stop,
.ndo_start_xmit = pxa_irda_hard_xmit,
.ndo_do_ioctl = pxa_irda_ioctl,
- .ndo_change_mtu = eth_change_mtu,
- .ndo_validate_addr = eth_validate_addr,
- .ndo_set_mac_address = eth_mac_addr,
};
static int pxa_irda_probe(struct platform_device *pdev)
@@ -847,6 +844,7 @@ static int pxa_irda_probe(struct platform_device *pdev)
if (!dev)
goto err_mem_3;
+ SET_NETDEV_DEV(dev, &pdev->dev);
si = netdev_priv(dev);
si->dev = &pdev->dev;
si->pdata = pdev->dev.platform_data;
--
1.6.3.3
^ permalink raw reply related
* Re: [RFC] [PATCH] Don't run __qdisc_run() on a stopped TX queue
From: David Miller @ 2009-07-28 4:21 UTC (permalink / raw)
To: herbert; +Cc: krkumar2, jarkao2, netdev
In-Reply-To: <20090728024813.GA23992@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 28 Jul 2009 10:48:13 +0800
> On Mon, Jul 27, 2009 at 07:28:44PM -0700, David Miller wrote:
>>
>> There is a locking benefit even for non-default qdiscs.
>>
>> Instead of two choke points (qdisc lock and queue lock) there
>> is now only one (qdisc lock) and consdiering the cost of
>> things like setting up IOMMU mappings and hitting chip
>> registers the qdisc lock is the shortest held of the two.
>
> But only one CPU can process a given qdisc at one time so I don't
> see why there is a second choke point if you use a single queue
> with a non-default qdisc.
Good point, but this only suggests that we might want to undo that
queue runner exclusivity state bit for this case especially when we
know that we are feeding a multiqueue device.
^ permalink raw reply
* Re: [PATCH v2] IPVS: logging sizeof(struct ip_vs_conn) on startup
From: Eric Dumazet @ 2009-07-28 5:38 UTC (permalink / raw)
To: Simon Horman
Cc: David Miller, heder, netdev, lvs-users, malcolm, linux-kernel
In-Reply-To: <20090728001926.GA20230@verge.net.au>
Simon Horman a écrit :
>
> Surprisingly its a very common question amongst users,
> because they want to know how much memory they need.
> It is of course all a bit silly, because the amount of
> memory used by the connection table is usually very small,
> but people still ask.
>
If SLUB is used
$ cat /sys/kernel/slab/ip_vs_conn/object_size
If SLAB is used, take fourth column of :
$ grep ip_vs_conn /proc/slabinfo
BTW these take into account L1 cache size alignment
^ permalink raw reply
* Re: net-next-2.6 phonet causes build error
From: Eric Dumazet @ 2009-07-28 6:18 UTC (permalink / raw)
To: David Miller; +Cc: remi.denis-courmont, netdev
In-Reply-To: <20090727.193157.168527559.davem@davemloft.net>
David Miller a écrit :
> From: Eric Dumazet <dada1@cosmosbay.com>
> Date: Mon, 27 Jul 2009 10:09:24 +0200
>
>> I currently use gcc-3.4.6, and current net-next-2.6 doesnt compile
>> for me (but linux-2.6 does compile properly so I just know this is
>> already fixed upstream)
>
> Eric, just FYI, I am not going to merge Linus's tree into
> net-2.6 (and therefore not into net-next-2.6 either) unless
> there is some conflict to resolve.
>
> So if you need this build fix, please integrate it locally
> by whatever means works best for you.
Thanks for the info David :)
Dont worry, I can deal with it !
^ permalink raw reply
* Re: [Bugme-new] [Bug 13760] New: 2.6.30 kernel locks up with pppoe in back trace (regression)
From: Igor M Podlesny @ 2009-07-28 6:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: bugzilla-daemon, bugme-daemon, netdev
In-Reply-To: <20090723000100.d74d6b1c.akpm@linux-foundation.org>
[...]
> Could have been a problem in net core, perhaps.
>
> Below is a ppp fix from 2.6.31, but it seems unlikely to fix your problem.
>
> It would help if we could see that trace, please. A digital photo
> would suit.
Here it is:
http://bugzilla.kernel.org/attachment.cgi?id=22516
(It's 2.6.30.3)
--
End of message. Next message?
^ permalink raw reply
* Re: [RFC] [PATCH] Don't run __qdisc_run() on a stopped TX queue
From: Jarek Poplawski @ 2009-07-28 6:43 UTC (permalink / raw)
To: David Miller; +Cc: herbert, krkumar2, netdev
In-Reply-To: <20090727.212107.161491585.davem@davemloft.net>
On Mon, Jul 27, 2009 at 09:21:07PM -0700, David Miller wrote:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Tue, 28 Jul 2009 10:48:13 +0800
>
> > On Mon, Jul 27, 2009 at 07:28:44PM -0700, David Miller wrote:
> >>
> >> There is a locking benefit even for non-default qdiscs.
> >>
> >> Instead of two choke points (qdisc lock and queue lock) there
> >> is now only one (qdisc lock) and consdiering the cost of
> >> things like setting up IOMMU mappings and hitting chip
> >> registers the qdisc lock is the shortest held of the two.
> >
> > But only one CPU can process a given qdisc at one time so I don't
> > see why there is a second choke point if you use a single queue
> > with a non-default qdisc.
>
> Good point, but this only suggests that we might want to undo that
> queue runner exclusivity state bit for this case especially when we
> know that we are feeding a multiqueue device.
I guess the main sacrifice of Herbert's idea is sch_multiq, and we
could probably consider some compromise like doing qdisc_run (with
qdisc_restart) a callback or only adding a "if default qdisc" check,
depending on costs/gains.
Jarek P.
^ 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