* Re: [RFC 00/72] Organize/Move of the Ethernet drivers in drivers/net/
From: Bill Fink @ 2011-06-26 7:54 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev
In-Reply-To: <1309010363-22750-1-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, 25 Jun 2011, Jeff Kirsher wrote:
> The following series is the first attempt to organize the drivers/net
> directory. This process was started a year ago, and the emphasis was
> on making the drivers/net/ easier to maintain and to group similar
> drivers into the appropriate sub-directory.
>
> The next steps are to move all the FIDDI drivers into drivers/net/fiddi,
> and like so. In addition, look at splitting the PS3 driver so that the
> wireless portion can be moved into /drivers/net/wireless.
That should be FDDI, not FIDDI.
-Bill
^ permalink raw reply
* Re: [RFC 00/72] Organize/Move of the Ethernet drivers in drivers/net/
From: Francois Romieu @ 2011-06-26 8:35 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev
In-Reply-To: <1309010363-22750-1-git-send-email-jeffrey.t.kirsher@intel.com>
Jeff Kirsher <jeffrey.t.kirsher@intel.com> :
> The following series is the first attempt to organize the drivers/net
> directory. This process was started a year ago, and the emphasis was
> on making the drivers/net/ easier to maintain and to group similar
> drivers into the appropriate sub-directory.
No opinion on the topic here. The changes look sane.
--
Ueimor
^ permalink raw reply
* Re: 2.6.39.2 BUG: unable to handle kernel NULL pointer dereference
From: Eric Dumazet @ 2011-06-26 9:56 UTC (permalink / raw)
To: Fabio Coatti; +Cc: linux-kernel, netdev
In-Reply-To: <BANLkTing9LWO6AjbdzOJzkJ9aoJhn_TLnw@mail.gmail.com>
Le dimanche 26 juin 2011 à 10:28 +0200, Fabio Coatti a écrit :
> I'm trying to boot with 2.6.39.2 but the process stops somewhere in
> network stack, with a BUG: report.
> I've been able to capture the kernel messages usign netconsole, so be
> patient with poor alignment :)
>
> Please note that at this moment I'm not subscribed to LKML, so please
> keep me in CC if any answer is required. Below you can find the
> netconsole trace and .config file.
>
> Thanks for the attention.
>
>
> ACPI: PCI Interrupt Link [LSMB] (IRQs 5 7 9 10 11 14 15) *0, disabled.
> br0: port 1(eth0) entering forwarding state
> i8042: PNP: No PS/2 controller found. Probing ports directly.
> serio: i8042 KBD port at 0x60,0x64 irq 1
> serio: i8042 AUX port at 0x60,0x64 irq 12
> mousedev: PS/2 mouse device common for all mice
> rtc_cmos 00:05: RTC can wake from S4
> rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
> rtc0: alarms up to one year, y3k, 242 bytes nvram, hpet irqs
> md: linear personality registered for level -1
> md: raid0 personality registered for level 0
> md: raid1 personality registered for level 1
> md: raid10 personality registered for level 10
> md: raid6 personality registered for level 6
> md: raid5 personality registered for level 5
> md: raid4 personality registered for level 4
> md: multipath personality registered for level -4
> device-mapper: uevent: version 1.0.3
> device-mapper: ioctl: 4.20.0-ioctl (2011-02-02) initialised: dm-devel@redhat.com
> cpuidle: using governor ladder
> Netfilter messages via NETLINK v0.30.
> TCP cubic registered
> NET: Registered protocol family 17
> NET: Registered protocol family 15
> Registering the dns_resolver key type
> rtc_cmos 00:05: setting system clock to 2011-06-26 08:10:48 UTC (1309075848)
> Freeing unused kernel memory: 6372k freed
> BUG: unable to handle kernel
> NULL pointer dereference
> at (null)
> IP:
> [< (null)>] (null)
> PGD 230a57067
> PUD 2309fb067
> PMD 0
>
> Oops: 0010 [#1]
> PREEMPT
> SMP
>
> last sysfs file: /sys/devices/virtual/net/br0/uevent
> CPU 2
>
> Modules linked in:
> bridge
> stp
> llc
> ip6t_rt
> ip6table_filter
> ip6_tables
> x_tables
> snd_usb_audio
> uvcvideo
> videodev
> snd_usbmidi_lib
> v4l2_compat_ioctl32
> snd_rawmidi
> snd_seq_device
> hid_logitech
> ipv6
> usbhid
> usb_storage
> usb_libusual
> uas
> snd_hda_codec_hdmi
> snd_hda_codec_analog
> ohci_hcd
> ehci_hcd
> snd_hda_intel
> snd_hda_codec
> k10temp
> i2c_nforce2
> snd_hwdep
> snd_pcm
> asus_atk0110
> snd_timer
> snd
> usbcore
> soundcore
> snd_page_alloc
>
>
> Pid: 3359, comm: ip Tainted: G W 2.6.39.2 #2
> System manufacturer System Product Name
> /M3N-HT DELUXE
>
> RIP: 0010:[<0000000000000000>]
> [< (null)>] (null)
> RSP: 0018:ffff8802264398a0 EFLAGS: 00010202
> RAX: 00000000000005dc RBX: 0000000000000320 RCX: ffff88022d38e608
> RDX: ffffffffa01d6fc0 RSI: ffffffffa01d5c61 RDI: ffff88022d38ee38
> RBP: ffff88022d38e000 R08: 0000000000000000 R09: ffff880230a5bb80
> R10: ffffffff81353339 R11: 0000000000000000 R12: ffff88022d38e600
> R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffa01d5870
> FS: 00007f4e5bb98700(0000) GS:ffff88023fd00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000000 CR3: 000000022640b000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process ip (pid: 3359, threadinfo ffff880226438000, task ffff880230ade300)
> Stack:
> ffffffffa01cc1e7
> ffff88022d38e000
> ffff8802264399a8
> 0000000000000000
>
> ffffffff8135bd0f
> ffff88022d38e000
> ffffffff81366ab9
> ffff88022d38e000
>
> ffff88022a4cfc10
> ffff880226439ae8
> 00000009a0124919
> ffff88022d39ed00
>
> Call Trace:
> [<ffffffffa01cc1e7>] ? br_change_mtu+0x50/0x6f [bridge]
> [<ffffffff8135bd0f>] ? dev_set_mtu+0x35/0x5b
> [<ffffffff81366ab9>] ? do_setlink+0x189/0x706
> [<ffffffff81365cfd>] ? rtnl_fill_ifinfo+0x954/0xa20
> [<ffffffff810925fd>] ? handle_mm_fault+0x107/0x189
> [<ffffffff8136738d>] ? rtnl_newlink+0x26a/0x4c1
> [<ffffffff813671d3>] ? rtnl_newlink+0xb0/0x4c1
> [<ffffffff813d7ead>] ? _raw_spin_unlock_irqrestore+0x20/0x2e
> [<ffffffff813553dc>] ? __skb_recv_datagram+0x103/0x23f
> [<ffffffff81366437>] ? rtnetlink_rcv+0x28/0x28
> [<ffffffff8137744b>] ? netlink_rcv_skb+0x34/0x7d
> [<ffffffff8136642e>] ? rtnetlink_rcv+0x1f/0x28
> [<ffffffff81377239>] ? netlink_unicast+0xe5/0x14d
> [<ffffffff813776da>] ? netlink_sendmsg+0x246/0x266
> [<ffffffff8134a6bb>] ? sock_sendmsg+0x83/0x9b
> [<ffffffff81091332>] ? __do_fault+0x396/0x3d1
> [<ffffffff8134a49f>] ? move_addr_to_kernel+0x2c/0x4a
> [<ffffffff8135463f>] ? verify_iovec+0x46/0x98
> [<ffffffff8134aae5>] ? sys_sendmsg+0x22c/0x2b4
> [<ffffffff810925fd>] ? handle_mm_fault+0x107/0x189
> [<ffffffff8101a773>] ? do_page_fault+0x29b/0x2d4
> [<ffffffff810960d3>] ? do_brk+0x2ca/0x326
> [<ffffffff813d887b>] ? system_call_fastpath+0x16/0x1b
> Code:
> Bad RIP value.
>
> RIP
> [< (null)>] (null)
> RSP <ffff8802264398a0>
> CR2: 0000000000000000
> ---[ end trace c2ce621f7ff96fed ]---
> br0: no IPv6 routers present
> br0: port 1(eth0) entering forwarding state
>
>
Hi Fabio
Could you test following patch :
http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6407d74c5106bb362b4087693688afd34942b094
This should be included in 2.6.39.3, if you confirm this fixes the
problem.
^ permalink raw reply
* Re: SKB paged fragment lifecycle on receive
From: Michael S. Tsirkin @ 2011-06-26 10:25 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev, xen-devel, Jeremy Fitzhardinge, Rusty Russell, mashirle
In-Reply-To: <1308930202.32717.144.camel@zakaz.uk.xensource.com>
On Fri, Jun 24, 2011 at 04:43:22PM +0100, Ian Campbell wrote:
> In this mode guest data pages ("foreign pages") were mapped into the
> backend domain (using Xen grant-table functionality) and placed into the
> skb's paged frag list (skb_shinfo(skb)->frags, I hope I am using the
> right term). Once the page is finished with netback unmaps it in order
> to return it to the guest (we really want to avoid returning such pages
> to the general allocation pool!).
Are the pages writeable by the source guest while netback processes
them? If yes, firewalling becomes unreliable as the packet can be
modified after it's checked, right?
Also, for guest to guest communication, do you wait for
the destination to stop looking at the packet in order
to return it to the source? If yes, can source guest
networking be disrupted by a slow destination?
> Jeremy Fitzhardinge and I subsequently
> looked at the possibility of a no-clone skb flag (i.e. always forcing a
> copy instead of a clone)
I think this is the approach that the patchset
'macvtap/vhost TX zero-copy support' takes.
> but IIRC honouring it universally turned into a
> very twisty maze with a number of nasty corner cases etc.
Any examples? Are they covered by the patchset above?
> FWIW I proposed a session on the subject for LPC this year.
We also plan to discuss this on kvm forum 2011
(colocated with linuxcon 2011).
http://www.linux-kvm.org/page/KVM_Forum_2011
--
MST
^ permalink raw reply
* [PATCH 00/12] Fix various section mismatches and build errors.
From: Ralf Baechle @ 2011-06-26 11:19 UTC (permalink / raw)
To: Andrew Morton, Alan Cox, Brent Casavant, David Airlie, "David
Cc: dri-devel, linux-kernel, linux-mips, linux-scsi, linux-serial,
netdev
I'm getting screen and screens full of section mismatches from my test
builds of the current kernel to the point where it's sometimes more
meaningful messages get hidden by the bulk of mismatches. This is the
first round of fixes with more to come.
Ralf
drivers/gpu/drm/radeon/radeon_clocks.c | 4 ++--
drivers/leds/leds-lp5521.c | 4 ++--
drivers/leds/leds-lp5523.c | 4 ++--
drivers/misc/ioc4.c | 2 +-
drivers/net/3c509.c | 2 +-
drivers/net/3c59x.c | 2 +-
drivers/net/depca.c | 25 +++++++++++++------------
drivers/net/hp100.c | 2 +-
drivers/net/ne3210.c | 12 +++++++-----
drivers/net/tulip/de4x5.c | 2 +-
drivers/scsi/sim710.c | 2 +-
drivers/tty/serial/Kconfig | 2 +-
12 files changed, 33 insertions(+), 30 deletions(-)
^ permalink raw reply
* [PATCH 04/12] NET: depca: Fix bucketload full of section mismatches.
From: Ralf Baechle @ 2011-06-26 11:23 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, linux-mips
In-Reply-To: <17dd5038b15d7135791aadbe80464a13c80758d3.1309182742.git.ralf@linux-mips.org>
WARNING: drivers/net/depca.o(.data+0x34): Section mismatch in reference from the variable depca_eisa_driver to the function .init.text:depca_eisa_probe()
The variable depca_eisa_driver references
the function __init depca_eisa_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
WARNING: drivers/net/depca.o(.devinit.text+0x2c): Section mismatch in reference from the function depca_isa_probe() to the function .init.text:depca_common_init()
The function __devinit depca_isa_probe() references
a function __init depca_common_init().
If depca_common_init is only used by depca_isa_probe then
annotate depca_common_init with a matching annotation.
WARNING: drivers/net/depca.o(.devinit.text+0x44): Section mismatch in reference from the function depca_isa_probe() to the function .init.text:depca_shmem_probe()
The function __devinit depca_isa_probe() references
a function __init depca_shmem_probe().
If depca_shmem_probe is only used by depca_isa_probe then
annotate depca_shmem_probe with a matching annotation.
WARNING: drivers/net/depca.o(.devinit.text+0x8c): Section mismatch in reference from the function depca_isa_probe() to the function .init.text:depca_hw_init()
The function __devinit depca_isa_probe() references
a function __init depca_hw_init().
If depca_hw_init is only used by depca_isa_probe then
annotate depca_hw_init with a matching annotation.
Fixing these in turn triggers yet more mismatches, fix those as well.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
To: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
---
drivers/net/depca.c | 25 +++++++++++++------------
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/net/depca.c b/drivers/net/depca.c
index 8b0084d..d40536a 100644
--- a/drivers/net/depca.c
+++ b/drivers/net/depca.c
@@ -331,7 +331,7 @@ static struct {
"DE422",\
""}
-static char* __initdata depca_signature[] = DEPCA_SIGNATURE;
+static char* __devinitdata depca_signature[] = DEPCA_SIGNATURE;
enum depca_type {
DEPCA, de100, de101, de200, de201, de202, de210, de212, de422, unknown
@@ -541,9 +541,9 @@ static void SetMulticastFilter(struct net_device *dev);
static int load_packet(struct net_device *dev, struct sk_buff *skb);
static void depca_dbg_open(struct net_device *dev);
-static u_char de1xx_irq[] __initdata = { 2, 3, 4, 5, 7, 9, 0 };
-static u_char de2xx_irq[] __initdata = { 5, 9, 10, 11, 15, 0 };
-static u_char de422_irq[] __initdata = { 5, 9, 10, 11, 0 };
+static u_char de1xx_irq[] __devinitdata = { 2, 3, 4, 5, 7, 9, 0 };
+static u_char de2xx_irq[] __devinitdata = { 5, 9, 10, 11, 15, 0 };
+static u_char de422_irq[] __devinitdata = { 5, 9, 10, 11, 0 };
static u_char *depca_irq;
static int irq;
@@ -580,7 +580,8 @@ static const struct net_device_ops depca_netdev_ops = {
.ndo_validate_addr = eth_validate_addr,
};
-static int __init depca_hw_init (struct net_device *dev, struct device *device)
+static int __devinit depca_hw_init (struct net_device *dev,
+ struct device *device)
{
struct depca_private *lp;
int i, j, offset, netRAM, mem_len, status = 0;
@@ -1302,7 +1303,7 @@ static void SetMulticastFilter(struct net_device *dev)
}
}
-static int __init depca_common_init (u_long ioaddr, struct net_device **devp)
+static int __devinit depca_common_init (u_long ioaddr, struct net_device **devp)
{
int status = 0;
@@ -1333,7 +1334,7 @@ static int __init depca_common_init (u_long ioaddr, struct net_device **devp)
/*
** Microchannel bus I/O device probe
*/
-static int __init depca_mca_probe(struct device *device)
+static int __devinit depca_mca_probe(struct device *device)
{
unsigned char pos[2];
unsigned char where;
@@ -1497,7 +1498,7 @@ static void __init depca_platform_probe (void)
}
}
-static enum depca_type __init depca_shmem_probe (ulong *mem_start)
+static enum depca_type __devinit depca_shmem_probe (ulong *mem_start)
{
u_long mem_base[] = DEPCA_RAM_BASE_ADDRESSES;
enum depca_type adapter = unknown;
@@ -1558,7 +1559,7 @@ static int __devinit depca_isa_probe (struct platform_device *device)
*/
#ifdef CONFIG_EISA
-static int __init depca_eisa_probe (struct device *device)
+static int __devinit depca_eisa_probe (struct device *device)
{
enum depca_type adapter = unknown;
struct eisa_device *edev;
@@ -1629,7 +1630,7 @@ static int __devexit depca_device_remove (struct device *device)
** and Boot (readb) ROM. This will also give us a clue to the network RAM
** base address.
*/
-static int __init DepcaSignature(char *name, u_long base_addr)
+static int __devinit DepcaSignature(char *name, u_long base_addr)
{
u_int i, j, k;
void __iomem *ptr;
@@ -1698,7 +1699,7 @@ static int __init DepcaSignature(char *name, u_long base_addr)
** PROM address counter is correctly positioned at the start of the
** ethernet address for later read out.
*/
-static int __init DevicePresent(u_long ioaddr)
+static int __devinit DevicePresent(u_long ioaddr)
{
union {
struct {
@@ -1751,7 +1752,7 @@ static int __init DevicePresent(u_long ioaddr)
** reason: access the upper half of the PROM with x=0; access the lower half
** with x=1.
*/
-static int __init get_hw_addr(struct net_device *dev)
+static int __devinit get_hw_addr(struct net_device *dev)
{
u_long ioaddr = dev->base_addr;
struct depca_private *lp = netdev_priv(dev);
--
1.7.4.4
^ permalink raw reply related
* [PATCH 06/12] NET: ne3210: Fix bucketload full of section mismatches.
From: Ralf Baechle @ 2011-06-26 11:26 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, linux-mips
In-Reply-To: <17dd5038b15d7135791aadbe80464a13c80758d3.1309182742.git.ralf@linux-mips.org>
WARNING: drivers/net/ne3210.o(.data+0x40): Section mismatch in reference from the variable ne3210_eisa_driver to the function .init.text:ne3210_eisa_probe()
The variable ne3210_eisa_driver references
the function __init ne3210_eisa_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Fixing this mismatch triggers yet more mismatches, fix those as well.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
To: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
---
drivers/net/ne3210.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ne3210.c b/drivers/net/ne3210.c
index 243ed2a..e30b8ff 100644
--- a/drivers/net/ne3210.c
+++ b/drivers/net/ne3210.c
@@ -80,17 +80,19 @@ static void ne3210_block_output(struct net_device *dev, int count, const unsigne
#define NE3210_DEBUG 0x0
-static unsigned char irq_map[] __initdata = {15, 12, 11, 10, 9, 7, 5, 3};
-static unsigned int shmem_map[] __initdata = {0xff0, 0xfe0, 0xfff0, 0xd8, 0xffe0, 0xffc0, 0xd0, 0x0};
-static const char *ifmap[] __initdata = {"UTP", "?", "BNC", "AUI"};
-static int ifmap_val[] __initdata = {
+static unsigned char irq_map[] __devinitdata = {15, 12, 11, 10, 9, 7, 5, 3};
+static unsigned int shmem_map[] __devinitdata = {
+ 0xff0, 0xfe0, 0xfff0, 0xd8, 0xffe0, 0xffc0, 0xd0, 0x0
+};
+static const char *ifmap[] __devinitdata = {"UTP", "?", "BNC", "AUI"};
+static int ifmap_val[] __devinitdata = {
IF_PORT_10BASET,
IF_PORT_UNKNOWN,
IF_PORT_10BASE2,
IF_PORT_AUI,
};
-static int __init ne3210_eisa_probe (struct device *device)
+static int __devinit ne3210_eisa_probe (struct device *device)
{
unsigned long ioaddr, phys_mem;
int i, retval, port_index;
--
1.7.4.4
^ permalink raw reply related
* [PATCH 07/12] NET: de4x5: Fix section mismatch
From: Ralf Baechle @ 2011-06-26 11:28 UTC (permalink / raw)
To: David S. Miller; +Cc: Grant Grundler, netdev, linux-kernel, linux-mips
In-Reply-To: <17dd5038b15d7135791aadbe80464a13c80758d3.1309182742.git.ralf@linux-mips.org>
WARNING: drivers/net/tulip/de4x5.o(.data+0x34): Section mismatch in reference from the variable de4x5_eisa_driver to the function .init.text:de4x5_eisa_probe()
The variable de4x5_eisa_driver references
the function __init de4x5_eisa_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
To: "David S. Miller" <davem@davemloft.net>
Cc: Grant Grundler <grundler@parisc-linux.org>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
---
drivers/net/tulip/de4x5.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tulip/de4x5.c b/drivers/net/tulip/de4x5.c
index efaa1d6..ea473b6 100644
--- a/drivers/net/tulip/de4x5.c
+++ b/drivers/net/tulip/de4x5.c
@@ -1995,7 +1995,7 @@ SetMulticastFilter(struct net_device *dev)
static u_char de4x5_irq[] = EISA_ALLOWED_IRQ_LIST;
-static int __init de4x5_eisa_probe (struct device *gendev)
+static int __devinit de4x5_eisa_probe (struct device *gendev)
{
struct eisa_device *edev;
u_long iobase;
--
1.7.4.4
^ permalink raw reply related
* Re: 2.6.39.2 BUG: unable to handle kernel NULL pointer dereference
From: Fabio Coatti @ 2011-06-26 11:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev
In-Reply-To: <1309082172.2532.31.camel@edumazet-laptop>
2011/6/26 Eric Dumazet <eric.dumazet@gmail.com>:
> Le dimanche 26 juin 2011 à 10:28 +0200, Fabio Coatti a écrit :
>> I'm trying to boot with 2.6.39.2 but the process stops somewhere in
>> network stack, with a BUG: report.
>> I've been able to capture the kernel messages usign netconsole, so be
>> patient with poor alignment :)
>
> Hi Fabio
>
> Could you test following patch :
>
> http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6407d74c5106bb362b4087693688afd34942b094
>
>
> This should be included in 2.6.39.3, if you confirm this fixes the
> problem.
>
Yes, I can confirm that your patch fixes the problem, now running
2.6.39.2 just fine. Many thanks!
--
Fabio
^ permalink raw reply
* Re: [RFC 46/72] ixp2000: Move the Radisys driver
From: Lennert Buytenhek @ 2011-06-26 11:47 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, Lennert Buytenhek
In-Reply-To: <1309010363-22750-47-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Jun 25, 2011 at 06:58:57AM -0700, Jeff Kirsher wrote:
> Move the Radisys driver into drivers/net/ethernet/radisys/ and
> make the necessary Kconfig and Makefile changes
>
> CC: Lennert Buytenhek <kernel@wantstofly.org>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> MAINTAINERS | 2 +-
> drivers/net/Kconfig | 2 --
> drivers/net/Makefile | 1 -
> drivers/net/ethernet/Kconfig | 1 +
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/ethernet/radisys/Kconfig | 16 ++++++++++++++++
> drivers/net/ethernet/radisys/Makefile | 5 +++++
> drivers/net/{ => ethernet/radisys}/ixp2000/Kconfig | 2 +-
> .../net/{ => ethernet/radisys}/ixp2000/Makefile | 0
The ixp2000 is a series of Intel ARM SoCs, and the ENP2611 is a Radisys
PCI board based on the ixp2000 series (ixp2400), so it doesn't make
sense to put everything in the radisys/ directory.
If you insist on moving all drivers into vendor directories (I don't
like that idea at all -- are we going to rename directories and shuffle
stuff around every time vendor A buys vendor B or takes over one of
vendor B's products?), at least the core ixp2000 code should be under
intel/.
^ permalink raw reply
* Re: 2.6.39.2 BUG: unable to handle kernel NULL pointer dereference
From: Eric Dumazet @ 2011-06-26 12:42 UTC (permalink / raw)
To: Fabio Coatti; +Cc: linux-kernel, netdev, David Miller
In-Reply-To: <BANLkTikhGVYAFEZGS-AZf3CyS4yVN+Acvg@mail.gmail.com>
Le dimanche 26 juin 2011 à 13:34 +0200, Fabio Coatti a écrit :
> 2011/6/26 Eric Dumazet <eric.dumazet@gmail.com>:
> > Le dimanche 26 juin 2011 à 10:28 +0200, Fabio Coatti a écrit :
> >> I'm trying to boot with 2.6.39.2 but the process stops somewhere in
> >> network stack, with a BUG: report.
> >> I've been able to capture the kernel messages usign netconsole, so be
> >> patient with poor alignment :)
>
> >
> > Hi Fabio
> >
> > Could you test following patch :
> >
> > http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6407d74c5106bb362b4087693688afd34942b094
> >
> >
> > This should be included in 2.6.39.3, if you confirm this fixes the
> > problem.
> >
>
> Yes, I can confirm that your patch fixes the problem, now running
> 2.6.39.2 just fine. Many thanks!
Thanks for testing, David will include this to his stable queue I
presume.
^ permalink raw reply
* Re: 2.6.39.2 BUG: unable to handle kernel NULL pointer dereference
From: David Miller @ 2011-06-26 12:57 UTC (permalink / raw)
To: eric.dumazet; +Cc: fabio.coatti, linux-kernel, netdev
In-Reply-To: <1309092147.2532.33.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 26 Jun 2011 14:42:27 +0200
> Le dimanche 26 juin 2011 à 13:34 +0200, Fabio Coatti a écrit :
>> 2011/6/26 Eric Dumazet <eric.dumazet@gmail.com>:
>> > Le dimanche 26 juin 2011 à 10:28 +0200, Fabio Coatti a écrit :
>> >> I'm trying to boot with 2.6.39.2 but the process stops somewhere in
>> >> network stack, with a BUG: report.
>> >> I've been able to capture the kernel messages usign netconsole, so be
>> >> patient with poor alignment :)
>>
>> >
>> > Hi Fabio
>> >
>> > Could you test following patch :
>> >
>> > http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6407d74c5106bb362b4087693688afd34942b094
>> >
>> >
>> > This should be included in 2.6.39.3, if you confirm this fixes the
>> > problem.
>> >
>>
>> Yes, I can confirm that your patch fixes the problem, now running
>> 2.6.39.2 just fine. Many thanks!
>
> Thanks for testing, David will include this to his stable queue I
> presume.
Yep, I will.
^ permalink raw reply
* [PATCH] net_sched: fix dequeuer fairness
From: jamal @ 2011-06-26 14:07 UTC (permalink / raw)
To: David Miller; +Cc: Eric Dumazet, Herbert Xu, netdev
[-- Attachment #1: Type: text/plain, Size: 325 bytes --]
Got the 10G intel cards installed finally and repeated
the tests on both dummy and Ixgbe. The unfairness was much
higher with 10G than with dummy. The logs contain the results.
I could send another patch with stats gathering.
The best place seems to be in net/softnet_stat re-using
the fast route entries.
cheers,
jamal
[-- Attachment #2: pns-1 --]
[-- Type: text/plain, Size: 3234 bytes --]
commit e7fbab65da4db8d2ef1a61c915dfa8c96c2e0368
Author: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Sun Jun 26 09:19:48 2011 -0400
[PATCH] net_sched: fix dequeuer fairness
Results on dummy device can be seen in my netconf 2011
slides. These results are for a 10Gige IXGBE intel
nic - on another i5 machine, very similar specs to
the one used in the netconf2011 results.
It turns out - this is a hell lot worse than dummy
and so this patch is even more beneficial for 10G.
Test setup:
----------
System under test sending packets out.
Additional box connected directly dropping packets.
Installed prio qdisc on the eth device and default
netdev default length of 1000 used as is.
The 3 prio bands each were set to 100 (didnt factor in
the results).
5 packet runs were made and the middle 3 picked.
results
-------
The "cpu" column indicates the which cpu the sample
was taken on,
The "Pkt runx" carries the number of packets a cpu
dequeued when forced to be in the "dequeuer" role.
The "avg" for each run is the number of times each
cpu should be a "dequeuer" if the system was fair.
3.0-rc4 (plain)
cpu Pkt run1 Pkt run2 Pkt run3
================================================
cpu0 21853354 21598183 22199900
cpu1 431058 473476 393159
cpu2 481975 477529 458466
cpu3 23261406 23412299 22894315
avg 11506948 11490372 11486460
3.0-rc4 with patch and default weight 64
cpu Pkt run1 Pkt run2 Pkt run3
================================================
cpu0 13205312 13109359 13132333
cpu1 10189914 10159127 10122270
cpu2 10213871 10124367 10168722
cpu3 13165760 13164767 13096705
avg 11693714 11639405 11630008
As you can see the system is still not perfect but
is a lot better than what it was before...
At the moment we use the old backlog weight, weight_p
which is 64 packets. It seems to be reasonably fine
with that value.
The system could be made more fair if we reduce the
weight_p (as per my presentation), but we are going
to affect the shared backlog weight. Unless deemed
necessary, I think the default value is fine. If not
we could add yet another knob.
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index b4c6809..578269e 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -190,14 +190,18 @@ static inline int qdisc_restart(struct Qdisc *q)
void __qdisc_run(struct Qdisc *q)
{
unsigned long start_time = jiffies;
+ int quota = 0;
+ int work = weight_p;
while (qdisc_restart(q)) {
+ quota++;
/*
- * Postpone processing if
- * 1. another process needs the CPU;
- * 2. we've been doing it for too long.
+ * Ordered by possible occurrence: Postpone processing if
+ * 1. we've exceeded packet quota
+ * 2. another process needs the CPU;
+ * 3. we've been doing it for too long.
*/
- if (need_resched() || jiffies != start_time) {
+ if (quota >= work || need_resched() || jiffies != start_time) {
__netif_schedule(q);
break;
}
^ permalink raw reply related
* Re: [PATCH 1/2] can: bfin_can: simplify xmit id1 setup
From: Wolfgang Grandegger @ 2011-06-26 14:14 UTC (permalink / raw)
To: Mike Frysinger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
In-Reply-To: <1308925982-14645-1-git-send-email-vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
On 06/24/2011 04:33 PM, Mike Frysinger wrote:
> If we look closely, the 4 writes to TRANSMIT_CHL.id1 can be collapsed
> down into much simpler code. So do just that.
>
> This also fixes a build failure due to the I/O macros no longer
> getting pulled in. Their minor (and accidental) usage here gets
> dropped as part of the unification.
>
> Signed-off-by: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Thanks,
Wolfgang,
^ permalink raw reply
* Re: [PATCH 2/2] can: bfin_can: auto-calculate accessor sizes
From: Wolfgang Grandegger @ 2011-06-26 14:15 UTC (permalink / raw)
To: Mike Frysinger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
In-Reply-To: <1308925982-14645-2-git-send-email-vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
On 06/24/2011 04:33 PM, Mike Frysinger wrote:
> Since we have a struct that defines the sizes of the registers, we don't
> need to explicitly use the 16bit read/write helpers. Let the code figure
> out which size access to make based on the size of the C type.
>
> There should be no functional changes here.
>
> Signed-off-by: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Thanks,
Wolfgang,
^ permalink raw reply
* Re: [PATCH] net_sched: fix dequeuer fairness
From: jamal @ 2011-06-26 14:17 UTC (permalink / raw)
To: David Miller; +Cc: Eric Dumazet, Herbert Xu, netdev
In-Reply-To: <1309097254.5134.24.camel@mojatatu>
[-- Attachment #1: Type: text/plain, Size: 478 bytes --]
Grr. A better tabulation (without tabs) of the results
on this one.
cheers,
jamal
On Sun, 2011-06-26 at 10:07 -0400, jamal wrote:
> Got the 10G intel cards installed finally and repeated
> the tests on both dummy and Ixgbe. The unfairness was much
> higher with 10G than with dummy. The logs contain the results.
>
> I could send another patch with stats gathering.
> The best place seems to be in net/softnet_stat re-using
> the fast route entries.
>
> cheers,
> jamal
[-- Attachment #2: pns-2 --]
[-- Type: text/plain, Size: 3237 bytes --]
commit e7fbab65da4db8d2ef1a61c915dfa8c96c2e0368
Author: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Sun Jun 26 09:19:48 2011 -0400
[PATCH] net_sched: fix dequeuer fairness
Results on dummy device can be seen in my netconf 2011
slides. These results are for a 10Gige IXGBE intel
nic - on another i5 machine, very similar specs to
the one used in the netconf2011 results.
It turns out - this is a hell lot worse than dummy
and so this patch is even more beneficial for 10G.
Test setup:
----------
System under test sending packets out.
Additional box connected directly dropping packets.
Installed prio qdisc on the eth device and default
netdev default length of 1000 used as is.
The 3 prio bands each were set to 100 (didnt factor in
the results).
5 packet runs were made and the middle 3 picked.
results
-------
The "cpu" column indicates the which cpu the sample
was taken on,
The "Pkt runx" carries the number of packets a cpu
dequeued when forced to be in the "dequeuer" role.
The "avg" for each run is the number of times each
cpu should be a "dequeuer" if the system was fair.
3.0-rc4 (plain)
cpu Pkt run1 Pkt run2 Pkt run3
================================================
cpu0 21853354 21598183 22199900
cpu1 431058 473476 393159
cpu2 481975 477529 458466
cpu3 23261406 23412299 22894315
avg 11506948 11490372 11486460
3.0-rc4 with patch and default weight 64
cpu Pkt run1 Pkt run2 Pkt run3
================================================
cpu0 13205312 13109359 13132333
cpu1 10189914 10159127 10122270
cpu2 10213871 10124367 10168722
cpu3 13165760 13164767 13096705
avg 11693714 11639405 11630008
As you can see the system is still not perfect but
is a lot better than what it was before...
At the moment we use the old backlog weight, weight_p
which is 64 packets. It seems to be reasonably fine
with that value.
The system could be made more fair if we reduce the
weight_p (as per my presentation), but we are going
to affect the shared backlog weight. Unless deemed
necessary, I think the default value is fine. If not
we could add yet another knob.
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index b4c6809..578269e 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -190,14 +190,18 @@ static inline int qdisc_restart(struct Qdisc *q)
void __qdisc_run(struct Qdisc *q)
{
unsigned long start_time = jiffies;
+ int quota = 0;
+ int work = weight_p;
while (qdisc_restart(q)) {
+ quota++;
/*
- * Postpone processing if
- * 1. another process needs the CPU;
- * 2. we've been doing it for too long.
+ * Ordered by possible occurrence: Postpone processing if
+ * 1. we've exceeded packet quota
+ * 2. another process needs the CPU;
+ * 3. we've been doing it for too long.
*/
- if (need_resched() || jiffies != start_time) {
+ if (quota >= work || need_resched() || jiffies != start_time) {
__netif_schedule(q);
break;
}
^ permalink raw reply related
* Re: [PATCH] net_sched: fix dequeuer fairness
From: Ben Hutchings @ 2011-06-26 14:53 UTC (permalink / raw)
To: jhs; +Cc: David Miller, Eric Dumazet, Herbert Xu, netdev
In-Reply-To: <1309097862.5134.26.camel@mojatatu>
On Sun, 2011-06-26 at 10:17 -0400, jamal wrote:
[...]
> diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
> index b4c6809..578269e 100644
> --- a/net/sched/sch_generic.c
> +++ b/net/sched/sch_generic.c
> @@ -190,14 +190,18 @@ static inline int qdisc_restart(struct Qdisc *q)
> void __qdisc_run(struct Qdisc *q)
> {
> unsigned long start_time = jiffies;
> + int quota = 0;
> + int work = weight_p;
These variable names seem to be the wrong way round, i.e. the weight is
our 'quota' and the number of packets dequeued is the 'work' we've done.
Ben.
> while (qdisc_restart(q)) {
> + quota++;
> /*
> - * Postpone processing if
> - * 1. another process needs the CPU;
> - * 2. we've been doing it for too long.
> + * Ordered by possible occurrence: Postpone processing if
> + * 1. we've exceeded packet quota
> + * 2. another process needs the CPU;
> + * 3. we've been doing it for too long.
> */
> - if (need_resched() || jiffies != start_time) {
> + if (quota >= work || need_resched() || jiffies != start_time) {
> __netif_schedule(q);
> break;
> }
>
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] net_sched: fix dequeuer fairness
From: Eric Dumazet @ 2011-06-26 15:09 UTC (permalink / raw)
To: jhs; +Cc: David Miller, Herbert Xu, netdev
In-Reply-To: <1309097254.5134.24.camel@mojatatu>
Le dimanche 26 juin 2011 à 10:07 -0400, jamal a écrit :
> Got the 10G intel cards installed finally and repeated
> the tests on both dummy and Ixgbe. The unfairness was much
> higher with 10G than with dummy. The logs contain the results.
>
> I could send another patch with stats gathering.
> The best place seems to be in net/softnet_stat re-using
> the fast route entries.
>
Hi Jamal
I would just remove the jiffies break, now we have a 64 packets limit...
if (quota >= work || need_resched()) {
...
}
^ permalink raw reply
* Re: [PATCH] net_sched: fix dequeuer fairness
From: jamal @ 2011-06-26 15:27 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, Eric Dumazet, Herbert Xu, netdev
In-Reply-To: <1309100033.3093.1499.camel@localhost>
On Sun, 2011-06-26 at 15:53 +0100, Ben Hutchings wrote:
> These variable names seem to be the wrong way round, i.e. the weight is
> our 'quota' and the number of packets dequeued is the 'work' we've done.
Makes sense - I will make the change.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] net_sched: fix dequeuer fairness
From: jamal @ 2011-06-26 15:32 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Herbert Xu, netdev
In-Reply-To: <1309100994.2532.35.camel@edumazet-laptop>
On Sun, 2011-06-26 at 17:09 +0200, Eric Dumazet wrote:
> I would just remove the jiffies break, now we have a 64 packets limit...
>
> if (quota >= work || need_resched()) {
> ...
> }
Seems reasonable to do. Some stats (on two different machines
at least with dummy) on a system with low # of processes:
~80% of the time - we exit the loop because of packet quota
~1% for both need_resched and jiffy
~19% simply because there were less than quota packets
Note: we do use a jiffy check on net_rx_action() but i suspect
we never ever hit it.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] net_sched: fix dequeuer fairness
From: Eric Dumazet @ 2011-06-26 15:53 UTC (permalink / raw)
To: jhs; +Cc: David Miller, Herbert Xu, netdev
In-Reply-To: <1309102334.5134.31.camel@mojatatu>
Le dimanche 26 juin 2011 à 11:32 -0400, jamal a écrit :
> On Sun, 2011-06-26 at 17:09 +0200, Eric Dumazet wrote:
>
>
> > I would just remove the jiffies break, now we have a 64 packets limit...
> >
> > if (quota >= work || need_resched()) {
> > ...
> > }
>
> Seems reasonable to do. Some stats (on two different machines
> at least with dummy) on a system with low # of processes:
> ~80% of the time - we exit the loop because of packet quota
> ~1% for both need_resched and jiffy
> ~19% simply because there were less than quota packets
>
> Note: we do use a jiffy check on net_rx_action() but i suspect
> we never ever hit it.
This is because of commit 24f8b2385e03a4f.
Prior to this, we could exit very fast from this function, even after
receiving a single packet.
jiffies break is kind of lazy, IMHO ;)
^ permalink raw reply
* Re: [PATCH] net_sched: fix dequeuer fairness
From: jamal @ 2011-06-26 16:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Herbert Xu, netdev
In-Reply-To: <1309102334.5134.31.camel@mojatatu>
[-- Attachment #1: Type: text/plain, Size: 79 bytes --]
Updated version of the patch with feedback from Ben and Eric.
cheers,
jamal
[-- Attachment #2: pns-3 --]
[-- Type: text/plain, Size: 3461 bytes --]
commit e8d4d1ef0584b1a9e7e3890f298da7aad7b7d111
Author: Jamal Hadi Salim <hadi@mojatatu.com>
Date: Sun Jun 26 11:51:04 2011 -0400
[PATCH] net_sched: fix dequeuer fairness
Results on dummy device can be seen in my netconf 2011
slides. These results are for a 10Gige IXGBE intel
nic - on another i5 machine, very similar specs to
the one used in the netconf2011 results.
It turns out - this is a hell lot worse than dummy
and so this patch is even more beneficial for 10G.
Test setup:
----------
System under test sending packets out.
Additional box connected directly dropping packets.
Installed prio qdisc on the eth device and default
netdev default length of 1000 used as is.
The 3 prio bands each were set to 100 (didnt factor in
the results).
5 packet runs were made and the middle 3 picked.
results
-------
The "cpu" column indicates the which cpu the sample
was taken on,
The "Pkt runx" carries the number of packets a cpu
dequeued when forced to be in the "dequeuer" role.
The "avg" for each run is the number of times each
cpu should be a "dequeuer" if the system was fair.
3.0-rc4 (plain)
cpu Pkt run1 Pkt run2 Pkt run3
================================================
cpu0 21853354 21598183 22199900
cpu1 431058 473476 393159
cpu2 481975 477529 458466
cpu3 23261406 23412299 22894315
avg 11506948 11490372 11486460
3.0-rc4 with patch and default weight 64
cpu Pkt run1 Pkt run2 Pkt run3
================================================
cpu0 13205312 13109359 13132333
cpu1 10189914 10159127 10122270
cpu2 10213871 10124367 10168722
cpu3 13165760 13164767 13096705
avg 11693714 11639405 11630008
As you can see the system is still not perfect but
is a lot better than what it was before...
At the moment we use the old backlog weight, weight_p
which is 64 packets. It seems to be reasonably fine
with that value.
The system could be made more fair if we reduce the
weight_p (as per my presentation), but we are going
to affect the shared backlog weight. Unless deemed
necessary, I think the default value is fine. If not
we could add yet another knob.
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index b4c6809..64195d0 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -190,14 +190,18 @@ static inline int qdisc_restart(struct Qdisc *q)
void __qdisc_run(struct Qdisc *q)
{
unsigned long start_time = jiffies;
+ int quota = weight_p;
+ int work = 0;
while (qdisc_restart(q)) {
+ work++;
/*
- * Postpone processing if
- * 1. another process needs the CPU;
- * 2. we've been doing it for too long.
+ * Ordered by possible occurrence: Postpone processing if
+ * 1. we've exceeded packet quota
+ * 2. another process needs the CPU;
+ * 3. we've been doing it for too long.
*/
- if (need_resched() || jiffies != start_time) {
+ if (work >= quota || need_resched()) {
__netif_schedule(q);
break;
}
^ permalink raw reply related
* Re: [PATCH] net_sched: fix dequeuer fairness
From: jamal @ 2011-06-26 16:13 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Herbert Xu, netdev
In-Reply-To: <1309103630.2532.42.camel@edumazet-laptop>
On Sun, 2011-06-26 at 17:53 +0200, Eric Dumazet wrote:
>
> This is because of commit 24f8b2385e03a4f.
>
> Prior to this, we could exit very fast from this function, even after
> receiving a single packet.
>
> jiffies break is kind of lazy, IMHO ;)
And subjective to the value of Hz.
In the case of net_rx_action it seems that we need
"something" other than packet budget to get us out of there
in extreme case when we loop and none of the netdevs have anything
to offer.
In the other extreme it would be very unfair to yield because
of jiffies when budget is not exhausted and devices have something
to offer.
One approach could be to deduct their napi weight when they
return a 0 for work done.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] net_sched: fix dequeuer fairness
From: Eric Dumazet @ 2011-06-26 16:26 UTC (permalink / raw)
To: jhs; +Cc: David Miller, Herbert Xu, netdev
In-Reply-To: <1309104215.5134.37.camel@mojatatu>
Le dimanche 26 juin 2011 à 12:03 -0400, jamal a écrit :
> Updated version of the patch with feedback from Ben and Eric.
>
Difficult to discuss about your patch because you didnt inline it :-(
You should remove this line in the comment
+ * 3. we've been doing it for too long.
^ permalink raw reply
* Re: [PATCH] net_sched: fix dequeuer fairness
From: jamal @ 2011-06-26 16:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Herbert Xu, netdev
In-Reply-To: <1309105599.2532.50.camel@edumazet-laptop>
On Sun, 2011-06-26 at 18:26 +0200, Eric Dumazet wrote:
> Difficult to discuss about your patch because you didnt inline it :-(
Evolution messes up with the whitespaces when i do that.
> You should remove this line in the comment
>
> + * 3. we've been doing it for too long.
yikes, yes.
cheers,
jamal
^ 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