* Re: Off-by-one error in net/8021q/vlan.c
From: Phil Karn @ 2011-02-21 21:47 UTC (permalink / raw)
To: Brent Cook
Cc: Michał Mirosław, Eric Dumazet, richard -rw- weinberger,
kaber, netdev
In-Reply-To: <201102211326.00255.bcook@breakingpoint.com>
On 2/21/11 11:26 AM, Brent Cook wrote:
>> Allowing it but with a big fat warning in logs is even better: "You
>> want your network broken? Sure, can do, but you have been warned."
*By all means* have vconfig issue a warning for 4095 just as it already
does for vlan 1.
As I explained the only reason I wanted to do this was to talk to a
piece of equipment that had been misconfigured to use vlan 4095 so I
could fix it. At the time I was using a newly built Linux system running
off a live CD, and only it had a physical network connection to the
device I was trying to fix.
I'm reminded of the classic example of an airliner that is so "smart"
and "idiot proof" that it always disallows a throttle setting that might
shorten the life of the engines.
The designers hadn't considered the possibility that such a setting
might be necessary to avoid a crash that, too, shortens engine life.
The obvious answer is to allow it but make sure he knows what he's
doing. So it takes noticeably more force to push the handles past the
safe limits, but it can be done if you really want to.
So if an airliner allows a command that might cause costly engine
damage, I think Linux can allow a command that violates a usage
convention written in a spec. With a warning, of course.
^ permalink raw reply
* 2.6.38-rc5-git6: Reported regressions from 2.6.37
From: Rafael J. Wysocki @ 2011-02-21 21:52 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Florian Mickler, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions from 2.6.37,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved regressions from 2.6.37, please let us
know either and we'll add them to the list. Also, please let us know
if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2011-02-21 51 18 17
2011-02-12 39 20 18
2011-02-03 19 11 7
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=29402
Subject : kernel panics while running ffsb scalability workloads on 2.6.38-rc1 through -rc5
Submitter : Eric Whitney <eric.whitney@hp.com>
Date : 2011-02-18 21:47 (4 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=29322
Subject : System lockup with 2.6.38-rc4+
Submitter : Chris Clayton <chris2553@googlemail.com>
Date : 2011-02-14 17:31 (8 days old)
Message-ID : <201102141731.29331.chris2553@googlemail.com>
References : http://marc.info/?l=linux-kernel&m=129770471724602&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=29252
Subject : IPv6 doesn't work in a kvm guest.
Submitter : Kusanagi Kouichi <slash@ac.auone-net.jp>
Date : 2011-02-16 13:03 (6 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=29232
Subject : [VT-d] VT-d device passthrough fail to guest
Submitter : xudong <xudong.hao@intel.com>
Date : 2011-02-16 08:56 (6 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=29202
Subject : 2.6.38-rc: fuse BUG, maybe related to detaching external usb drive without umounting
Submitter : Florian Mickler <florian@mickler.org>
Date : 2011-02-15 22:05 (7 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=29022
Subject : [REGRESSION? 2.6.38-rc4] nouveau NV50 screen freeze
Submitter : Marc <marc@osknowledge.org>
Date : 2011-02-13 12:29 (9 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28882
Subject : Screen corruption and GPU hangs
Submitter : Ko Mi <chaostya.test@hotmail.com>
Date : 2011-02-11 18:17 (11 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28842
Subject : 2.6.38-rc3 regression ipv6 TFTP download with curl failing in getpeername?
Submitter : Eric W. Biederman <ebiederm@xmission.com>
Date : 2011-02-08 9:41 (14 days old)
Message-ID : <m1ei7iamnn.fsf@fess.ebiederm.org>
References : http://marc.info/?l=linux-kernel&m=129715811421534&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28642
Subject : ACPI broken on DELL Latitude E6410 in 2.6.38-rc3
Submitter : Adam Kovari <kovariadam@gmail.com>
Date : 2011-02-08 22:22 (14 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28562
Subject : [BUG] usb problems in .38-rc3+
Submitter : Ed Tomlinson <edt@aei.ca>
Date : 2011-02-05 19:17 (17 days old)
Message-ID : <201102051417.58953.edt@aei.ca>
References : http://marc.info/?l=linux-kernel&m=129693391417607&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28522
Subject : Unable to mount FAT-formatted floppy on /dev/fd0, plus WARN_ON when using /dev/fd0u1440
Submitter : Alex Villacis Lasso <avillaci@ceibo.fiec.espol.edu.ec>
Date : 2011-02-07 17:21 (15 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28452
Subject : 2.6.38-rc3 regression on parisc: segfaults
Submitter : Meelis Roos <mroos@linux.ee>
Date : 2011-02-01 22:00 (21 days old)
Message-ID : <alpine.SOC.1.00.1102012342200.25944@math.ut.ee>
References : http://marc.info/?l=linux-kernel&m=129659763426600&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28432
Subject : khugepaged: gets stuck when writing to USB flash, 2.6.38-rc2
Submitter : Jindřich Makovička <makovick@gmail.com>
Date : 2011-01-31 19:28 (22 days old)
Message-ID : <AANLkTi=uOpN0PwWdGh6iri-vJwuMS+WMPxmaZjv0-TrV@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=129650210516627&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28422
Subject : kref and apparmor panic in 2.6.38-rc2.
Submitter : Tao Ma <tm@tao.ma>
Date : 2011-01-31 10:06 (22 days old)
Message-ID : <4D46899B.80302@tao.ma>
References : http://marc.info/?l=linux-kernel&m=129646840303149&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28262
Subject : Slow resume from suspend/hibernate on Dell Inspiron M301Z
Submitter : Luca Ferretti <lferrett@gnome.org>
Date : 2011-02-05 12:37 (17 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28102
Subject : New display errors in 2.6.38-rc2-00175-g6fb1b30
Submitter : Nico Schottelius <nico-kernel-20110117@schottelius.org>
Date : 2011-01-28 20:29 (25 days old)
Message-ID : <20110128202905.GB3395@schottelius.org>
References : http://marc.info/?l=linux-kernel&m=129624657425949&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27022
Subject : [REPORT] BUG: spinlock recursion on CPU#0, init/1
Submitter : Santosh Shilimkar <santosh.shilimkar@ti.com>
Date : 2011-01-10 15:33 (43 days old)
Message-ID : <a7a9bdaa5936630925fb7ffd1a1795b1@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=129467294808655&w=2
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27382
Subject : ath5k phy0: gain calibration timeout
Submitter : Nicolas Stransky <Nico@stransky.cx>
Date : 2011-01-23 00:18 (30 days old)
Handled-By : Nick Kossifidis <mickflemm@gmail.com>
Patch : https://patchwork.kernel.org/patch/530811/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.37,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=27352
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* 2.6.38-rc5-git6: Reported regressions 2.6.36 -> 2.6.37
From: Rafael J. Wysocki @ 2011-02-21 22:29 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Florian Mickler, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
[NOTE: Can maintainers _please_ merge patches listed below, especially those that
have been known for weeks?]
This message contains a list of some post-2.6.36 regressions introduced before
2.6.37, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved post-2.6.36 regressions, please let us know
either and we'll add them to the list. Also, please let us know if any
of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2011-02-21 128 35 26
2011-02-13 126 36 30
2011-02-03 118 36 31
2010-12-30 85 32 26
2010-12-19 73 28 24
2010-12-03 55 25 19
2010-11-19 39 29 25
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=29172
Subject : releasing loop on top of other loop leads to deadlock
Submitter : Petr Uzel <petr.uzel@centrum.cz>
Date : 2011-02-15 10:00 (7 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28812
Subject : DVI attached monitor is turned off while booting linux 2.6.37 and higher
Submitter : Markus Heinz <markus.heinz@uni-dortmund.de>
Date : 2011-02-10 19:33 (12 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28772
Subject : oops in nfs_revalidate_mapping
Submitter : Daniel Poelzleithner <bugzilla.kernel.org@poelzi.org>
Date : 2011-02-10 13:59 (12 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28662
Subject : i915 in kernel 2.6.38-rc4, high number of wakeups
Submitter : Kan-Ru Chen <kanru@kanru.info>
Date : 2011-02-09 07:06 (13 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28622
Subject : radeon video lockup
Submitter : Daniel Poelzleithner <bugzilla.kernel.org@poelzi.org>
Date : 2011-02-08 17:48 (14 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28612
Subject : regular soft lockup
Submitter : Alexandre Demers <alexandre.f.demers@gmail.com>
Date : 2011-02-08 16:39 (14 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28582
Subject : whole system hang when start X
Submitter : Gu Rui <chaos.proton@gmail.com>
Date : 2011-02-08 08:33 (14 days old)
First-Bad-Commit: http://git.kernel.org/linus/d5bb081b027b520f9e59b4fb8faea83a136ec15e
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28332
Subject : [RV620] Can not re-enable LVDS after using HDMI only
Submitter : Rafał Miłecki <zajec5@gmail.com>
Date : 2011-02-05 22:42 (17 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27892
Subject : SNB: GPU hang with Slip xscreensaver
Submitter : Takashi Iwai <tiwai@suse.de>
Date : 2011-01-31 12:06 (22 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27842
Subject : [regression?] hang with 2.6.37 on a BTRFS test machine
Submitter : Martin Steigerwald <Martin@lichtvoll.de>
Date : 2011-01-23 12:06 (30 days old)
Message-ID : <<201101231306.23069.Martin@lichtvoll.de>>
References : http://marc.info/?l=linux-kernel&m=129578445613283&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27642
Subject : 2.6.37 says WARNING: at arch/x86/kernel/apic/apic.c:1287 setup_local_APIC+0x18f/0x263()
Submitter : Rob Landley <rlandley@parallels.com>
Date : 2011-01-18 13:11 (35 days old)
Message-ID : <4D359188.3040408@parallels.com>
References : http://marc.info/?l=linux-kernel&m=129535632319892&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27402
Subject : Atheros adapter no longer loads firmware
Submitter : Michal Vaner <vorner@ucw.cz>
Date : 2011-01-23 15:29 (30 days old)
First-Bad-Commit: http://git.kernel.org/linus/be93112accb42c5586a459683d71975cc70673ca
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27152
Subject : VGA output broken at cold boot
Submitter : Takashi Iwai <tiwai@suse.de>
Date : 2011-01-20 13:26 (33 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27132
Subject : flush-btrfs gets into an infinite loop
Submitter : Artem Anisimov <aanisimov@inbox.ru>
Date : 2011-01-20 11:51 (33 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26802
Subject : b43: Suspend failed
Submitter : Patrick Matthäi <patrick@linux-dev.org>
Date : 2011-01-15 18:56 (38 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26612
Subject : BUG in fs/inode.c:429
Submitter : Florian Kriener <florian@kriener.org>
Date : 2011-01-06 16:35 (47 days old)
Message-ID : <201101061735.40060.florian@kriener.org>
References : http://marc.info/?l=linux-kernel&m=129433235223735&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26582
Subject : NULL pointer dereference on pipe creation
Submitter : Ferenc Wágner <wferi@niif.hu>
Date : 2011-01-12 13:30 (41 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26112
Subject : [LogFS] [2.6.37-rc8+] Kernel BUG at logfs/readwrite.c:297!
Submitter : Prasad Joshi <prasadjoshi124@gmail.com>
Date : 2011-01-02 21:22 (51 days old)
Message-ID : <AANLkTinpoM8FuG8UkF88xs_V37dz_wgE8t-s0JPzaS-w@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=129400335910652&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26102
Subject : [2.6.37-rc8] BUG kmalloc-256: Poison overwritten.
Submitter : Pawel Sikora <pluto@agmk.net>
Date : 2010-12-30 15:08 (54 days old)
Message-ID : <201012301608.40859.pluto@agmk.net>
References : http://marc.info/?l=linux-kernel&m=129372388925679&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25832
Subject : kernel crashes upon resume if usb devices are removed when suspended
Submitter : rocko <rockorequin@hotmail.com>
Date : 2010-12-29 11:47 (55 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25732
Subject : i915 turns picture green when display switched off-on
Submitter : Tõnu Raitviir <jussuf@linux.ee>
Date : 2010-12-27 22:14 (57 days old)
First-Bad-Commit: http://git.kernel.org/linus/3c17fe4b8f40a112a85758a9ab2aebf772bdd647
Handled-By : Chris Wilson <chris@chris-wilson.co.uk>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24882
Subject : PM/Hibernate: Memory corruption patch introduces regression (2.6.36.2)
Submitter : <akwatts@ymail.com>
Date : 2010-12-14 04:00 (70 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24822
Subject : Embedded DisplayPort is detected wrongly on HP ProBook 5320m
Submitter : Takashi Iwai <tiwai@suse.de>
Date : 2010-12-13 11:09 (71 days old)
Handled-By : Chris Wilson <chris@chris-wilson.co.uk>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22942
Subject : [2.6.37-rc1, OOM] virtblk: OOM in do_virtblk_request()
Submitter : Dave Chinner <david@fromorbit.com>
Date : 2010-11-05 1:30 (109 days old)
Message-ID : <20101105013003.GE13830@dastard>
References : http://marc.info/?l=linux-kernel&m=128892062917641&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22642
Subject : 2.6.37-rc1: Disk takes 10 seconds to resume - MacBook2,1
Submitter : Tobias <devnull@plzk.org>
Date : 2010-11-10 19:33 (104 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22542
Subject : [2.6.37-rc1] drm:i195 errors
Submitter : Paul Rolland <rol@witbe.net>
Date : 2010-11-02 14:58 (112 days old)
Message-ID : <20101102155813.09cb2c6e@tux.DEF.witbe.net>
References : http://marc.info/?l=linux-kernel&m=128870991628970&w=2
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27532
Subject : ath9k prevents CPU from entering lower C-states
Submitter : Thomas Bächler <thomas@archlinux.org>
Date : 2011-01-24 22:43 (29 days old)
Handled-By : Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=47952
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27202
Subject : Remote control of saa7134-based tv card "ASUSTeK P7131 Hybrid" stopped working in 2.6.37
Submitter : <acaizzo@gmail.com>
Date : 2011-01-20 17:23 (33 days old)
First-Bad-Commit: http://git.kernel.org/linus/4651918a4afdd49bdea21d2f919b189ef17a6399
Handled-By : Mauro Carvalho Chehab <mchehab@redhat.com>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=44532
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25922
Subject : IdeaPad Y530 brightness keys not functioning
Submitter : Tomasz <tm.temp@gmx.com>
Date : 2010-12-30 12:48 (54 days old)
Patch : https://bugzilla.kernel.org/attachment.cgi?id=48542
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25822
Subject : [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8
Submitter : Gurudas Pai <gurudas.pai@oracle.com>
Date : 2010-12-29 6:58 (55 days old)
Message-ID : <4D1AD935.1020504@oracle.com>
References : http://marc.info/?l=linux-kernel&m=129360511222037&w=2
Handled-By : Miklos Szeredi <mszeredi@suse.cz>
Patch : https://lkml.org/lkml/2010/12/29/131
https://lkml.org/lkml/2011/1/20/163
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25402
Subject : kernel (2.6.37-8-generic_amd64) panic on boot (with message "map_single: bounce buffer is not DMA'ble) - possible regression !!!
Submitter : carlos <carlos.palma@ono.com>
Date : 2010-12-21 19:58 (63 days old)
Handled-By : FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Patch : https://patchwork.kernel.org/patch/522971/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24982
Subject : Inconsistent DPMS handling with 2.6.37 DRM
Submitter : Takashi Iwai <tiwai@suse.de>
Date : 2010-12-16 16:32 (68 days old)
Handled-By : Takashi Iwai <tiwai@suse.de>
Keith Packard <keithp@keithp.com>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=40392
https://patchwork.kernel.org/patch/530921/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24582
Subject : Kernel Oops at tty_buffer_request_room when using pppd program (2.6.37-rc4)
Submitter : baoyb <baoyb@avit.org.cn>
Date : 2010-12-08 13:55 (76 days old)
Message-ID : <EF6DDE218DB34702B1FA84D6CD7EA771@baoyb>
References : http://marc.info/?l=linux-kernel&m=129181763525738&w=2
Handled-By : Jiri Slaby <jslaby@suse.cz>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=47872
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23472
Subject : 2.6.37-rc2 vs. 2.6.36 laptop backlight changes?
Submitter : Patrick Schaaf <netdev@bof.de>
Date : 2010-11-17 13:41 (97 days old)
Message-ID : <1290001262.5727.2.camel@lat1>
References : http://marc.info/?l=linux-kernel&m=129000127920912&w=2
Handled-By : Indan Zupancic <indan@nul.nu>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=47302
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22882
Subject : (2.6.37-rc1) amd64-agp module crashed on second load
Submitter : Randy Dunlap <randy.dunlap@oracle.com>
Date : 2010-11-05 0:13 (109 days old)
Message-ID : <20101104171333.fea1f498.randy.dunlap@oracle.com>
References : http://marc.info/?l=linux-kernel&m=128891605213447&w=2
Handled-By : Florian Mickler <florian@mickler.org>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=46682
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.36 and 2.6.37, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=21782
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* [PATCH net-next-2.6] bonding: fix user-controlled queuing issues
From: Andy Gospodarek @ 2011-02-21 22:53 UTC (permalink / raw)
To: netdev, Ben Hutchings, Jay Vosburgh, Phil Oester
Users noticed the following messages were filling their logs when using
queue 16 for user-mode bonding:
kernel: bond0 selects TX queue 16, but real number of TX queues is 16
These messages were showing up since the code for setting queues
presumed that queues 1-16 were usable and queue 0 was reserved, but
parts of the code didn't account for this correctly. This update now
allows 16 queues (numbered 0-15) to be used (in the nominal case) and
queue awareness can be completely and clearly disabled rather than by
simply setting the queue for a device to 0.
Configuration syntax has changed a little, but is similar to the
existing method. To associate a queue with an output device, you can do
this:
# echo "+eth1:2" > /sys/class/net/bond0/bonding/queue_id
and to clear it this:
# echo "-eth1:2" > /sys/class/net/bond0/bonding/queue_id
The orginal report that prompted this patch changed bond_select_queue to
return a value different than sinply skb->queue_mapping. This should
now be a proper return value since the interal queues were remapped
internally and queues 0-15 are the usable queues.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Reported-by: Phil Oester <kernel@linuxace.com>
---
My tests all seem to work well, but more testing/feedback is obviously
appreciated.
---
Documentation/networking/bonding.txt | 20 ++++++----
drivers/net/bonding/bond_main.c | 16 ++++---
drivers/net/bonding/bond_sysfs.c | 71 +++++++++++++++++++++------------
drivers/net/bonding/bonding.h | 20 +++++++++
4 files changed, 86 insertions(+), 41 deletions(-)
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 25d2f41..8a27f0f 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -1404,10 +1404,11 @@ By default the bonding driver is multiqueue aware and 16 queues are created
when the driver initializes (see Documentation/networking/multiqueue.txt
for details). If more or less queues are desired the module parameter
tx_queues can be used to change this value. There is no sysfs parameter
-available as the allocation is done at module init time.
+available as the allocation is done at module init time. Currently only one
+queue per device can be set.
The output of the file /proc/net/bonding/bondX has changed so the output Queue
-ID is now printed for each slave:
+ID is now printed for each slave that has a queue configured:
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
@@ -1421,7 +1422,6 @@ Slave Interface: eth0
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:1a:a0:12:8f:cb
-Slave queue ID: 0
Slave Interface: eth1
MII Status: up
@@ -1431,12 +1431,16 @@ Slave queue ID: 2
The queue_id for a slave can be set using the command:
-# echo "eth1:2" > /sys/class/net/bond0/bonding/queue_id
+# echo "+eth1:2" > /sys/class/net/bond0/bonding/queue_id
-Any interface that needs a queue_id set should set it with multiple calls
-like the one above until proper priorities are set for all interfaces. On
-distributions that allow configuration via initscripts, multiple 'queue_id'
-arguments can be added to BONDING_OPTS to set all needed slave queues.
+and removed using the command:
+
+# echo "-eth1:2" > /sys/class/net/bond0/bonding/queue_id
+
+Any interface that needs a queue_id set should set it with multiple calls until
+proper priorities are set or cleared for all interfaces. On distributions that
+allow configuration via initscripts, multiple 'queue_id' arguments can be added
+to BONDING_OPTS to set all needed slave queues.
These queue id's can be used in conjunction with the tc utility to configure
a multiqueue qdisc and filters to bias certain traffic to transmit on certain
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 77e3c6a..c9723d6 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1560,8 +1560,8 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
}
/*
- * Set the new_slave's queue_id to be zero. Queue ID mapping
- * is set via sysfs or module option if desired.
+ * Set the new_slave's queue_id to be zero to disable. Queue ID
+ * mapping is set via sysfs.
*/
new_slave->queue_id = 0;
@@ -3355,7 +3355,8 @@ static void bond_info_show_slave(struct seq_file *seq,
else
seq_puts(seq, "Aggregator ID: N/A\n");
}
- seq_printf(seq, "Slave queue ID: %d\n", slave->queue_id);
+ if (slave_tx_queue_recorded(slave))
+ seq_printf(seq, "Slave queue ID: %d\n", slave_get_tx_queue(slave));
}
static int bond_info_seq_show(struct seq_file *seq, void *v)
@@ -4516,15 +4517,16 @@ static inline int bond_slave_override(struct bonding *bond,
/* Find out if any slaves have the same mapping as this skb. */
bond_for_each_slave(bond, check_slave, i) {
- if (check_slave->queue_id == skb->queue_mapping) {
+ if (slave_tx_queue_recorded(check_slave) &&
+ slave_get_tx_queue(check_slave) == skb->queue_mapping) {
slave = check_slave;
break;
}
}
/* If the slave isn't UP, use default transmit policy. */
- if (slave && slave->queue_id && IS_UP(slave->dev) &&
- (slave->link == BOND_LINK_UP)) {
+ if (slave && slave_tx_queue_recorded(slave) &&
+ IS_UP(slave->dev) && (slave->link == BOND_LINK_UP)) {
res = bond_dev_queue_xmit(bond, skb, slave->dev);
}
@@ -4537,7 +4539,7 @@ static u16 bond_select_queue(struct net_device *dev, struct sk_buff *skb)
{
/*
* This helper function exists to help dev_pick_tx get the correct
- * destination queue. Using a helper function skips the a call to
+ * destination queue. Using a helper function skips the call to
* skb_tx_hash and will put the skbs in the queue we expect on their
* way down to the bonding driver.
*/
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 72bb0f6..d09701f 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -1448,15 +1448,18 @@ static ssize_t bonding_show_queue_id(struct device *d,
read_lock(&bond->lock);
bond_for_each_slave(bond, slave, i) {
- if (res > (PAGE_SIZE - IFNAMSIZ - 6)) {
- /* not enough space for another interface_name:queue_id pair */
- if ((PAGE_SIZE - res) > 10)
- res = PAGE_SIZE - 10;
- res += sprintf(buf + res, "++more++ ");
- break;
+ if (slave_tx_queue_recorded(slave)) {
+ if (res > (PAGE_SIZE - IFNAMSIZ - 6)) {
+ /* Not enough space for another
+ * interface_name:queue_id pair. */
+ if ((PAGE_SIZE - res) > 10)
+ res = PAGE_SIZE - 10;
+ res += sprintf(buf + res, "++more++ ");
+ break;
+ }
+ res += sprintf(buf + res, "%s:%d ", slave->dev->name,
+ slave_get_tx_queue(slave));
}
- res += sprintf(buf + res, "%s:%d ",
- slave->dev->name, slave->queue_id);
}
read_unlock(&bond->lock);
if (res)
@@ -1479,55 +1482,71 @@ static ssize_t bonding_store_queue_id(struct device *d,
int i, ret = count;
char *delim;
struct net_device *sdev = NULL;
+ char command[IFNAMSIZ + 7] = {0, };
+ char *ifname;
if (!rtnl_trylock())
return restart_syscall();
+ sscanf(buffer, "%22s", command); /* IFNAMSIZ*/
+
/* delim will point to queue id if successful */
- delim = strchr(buffer, ':');
+ delim = strchr(command + 1, ':');
if (!delim)
goto err_no_cmd;
-
/*
* Terminate string that points to device name and bump it
* up one, so we can read the queue id there.
*/
*delim = '\0';
- if (sscanf(++delim, "%hd\n", &qid) != 1)
+ if (sscanf(++delim, "%hd\n", &qid) != 1) {
goto err_no_cmd;
+ }
- /* Check buffer length, valid ifname and queue id */
- if (strlen(buffer) > IFNAMSIZ ||
- !dev_valid_name(buffer) ||
- qid > bond->params.tx_queues)
+ /* ifname will now be command + 1 */
+ ifname = command + 1;
+ if ((strlen(command) <= 1) ||
+ !dev_valid_name(ifname) ||
+ qid >= bond->params.tx_queues)
goto err_no_cmd;
/* Get the pointer to that interface if it exists */
- sdev = __dev_get_by_name(dev_net(bond->dev), buffer);
+ sdev = __dev_get_by_name(dev_net(bond->dev), ifname);
if (!sdev)
goto err_no_cmd;
read_lock(&bond->lock);
- /* Search for thes slave and check for duplicate qids */
+ /* Search for the slave needing the change */
update_slave = NULL;
bond_for_each_slave(bond, slave, i) {
if (sdev == slave->dev)
- /*
- * We don't need to check the matching
- * slave for dups, since we're overwriting it
- */
update_slave = slave;
- else if (qid && qid == slave->queue_id) {
+ else if (slave_tx_queue_recorded(slave) &&
+ qid == slave_get_tx_queue(slave)) {
goto err_no_cmd_unlock;
}
}
-
if (!update_slave)
goto err_no_cmd_unlock;
- /* Actually set the qids for the slave */
- update_slave->queue_id = qid;
+ /* at this point we have a valid slave */
+ switch (command[0]) {
+ case '+':
+ if (slave_tx_queue_recorded(update_slave))
+ goto err_no_cmd_unlock;
+ slave_record_tx_queue(update_slave, qid);
+ break;
+ case '-':
+ if (!slave_tx_queue_recorded(update_slave) ||
+ slave_get_tx_queue(update_slave) != qid)
+ goto err_no_cmd_unlock;
+ slave_clear_tx_queue(update_slave);
+ break;
+
+ default:
+ goto err_no_cmd;
+ }
read_unlock(&bond->lock);
out:
@@ -1537,7 +1556,7 @@ out:
err_no_cmd_unlock:
read_unlock(&bond->lock);
err_no_cmd:
- pr_info("invalid input for queue_id set for %s.\n",
+ pr_info("cannot modify queue_id for %s.\n",
bond->dev->name);
ret = -EPERM;
goto out;
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 31fe980..c9059f4 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -422,4 +422,24 @@ static inline void bond_unregister_ipv6_notifier(void)
}
#endif
+static inline void slave_record_tx_queue(struct slave *slave, u16 tx_queue)
+{
+ slave->queue_id = tx_queue + 1;
+}
+
+static inline u16 slave_get_tx_queue(const struct slave *slave)
+{
+ return slave->queue_id - 1;
+}
+
+static inline bool slave_tx_queue_recorded(const struct slave *slave)
+{
+ return slave->queue_id != 0;
+}
+
+static inline void slave_clear_tx_queue(struct slave *slave)
+{
+ slave->queue_id = 0;
+}
+
#endif /* _LINUX_BONDING_H */
^ permalink raw reply related
* Re: [patch net-next-2.6 V3] net: convert bonding to use rx_handler
From: Nicolas de Pesloüan @ 2011-02-21 23:20 UTC (permalink / raw)
To: Jiri Pirko
Cc: Jay Vosburgh, David Miller, kaber, eric.dumazet, netdev,
shemminger, andy, Fischer, Anna
In-Reply-To: <20110220150710.GB2750@psychotron.redhat.com>
Le 20/02/2011 16:07, Jiri Pirko a écrit :
> Sun, Feb 20, 2011 at 01:12:01PM CET, nicolas.2p.debian@gmail.com wrote:
[snip]
>> And thinking about all this, I wonder what the protocol handlers expect as the orig_dev value ?
>>
>> Lets imagine the following configuration: eth0 -> bond0 -> br0.
>>
>> What does a protocol handler listening on br0 expect for orig_dev ?
>> bond0 or eth0 ? Current implementation give eth0, but I think bond0
>> should be the right value, for proper nesting.
>
> I agree with you.
[snip}
>>> This hook is something I do not like at all :/ But anyway if should be in vlan
>>> part I think.
>>
>> Yes, and in order for the future rx_handler for vlan to properly
>> handle it, it needs to know the device just below it, not the pure
>> original device. Hence, my question about the exact meaning of
>> orig_dev...
After checking every protocol handlers installed by dev_add_pack(), it appears that only 4 of them
really use the orig_dev parameter given by __netif_receive_skb():
- bond_3ad_lacpdu_recv() @ drivers/net/bonding/bond_3ad.c
- bond_arp_recv() @ drivers/net/bonding/bond_main.c
- packet_rcv() @ net/packet/af_packet.c
- tpacket_rcv() @ net/packet/af_packet.c
From the bonding point of view, the meaning of orig_dev is obviously "the device one layer below
the bonding device, through which the packet reached the bonding device". It is used by
bond_3ad_lacpdu_recv() and bond_arp_recv(), to find the underlying slave device through which the
LACPDU or ARP was received. (The protocol handler is registered at the bonding device level).
From the af_packet point of view, the meaning is documented (in commit "[AF_PACKET]: Add option to
return orig_dev to userspace") as the "physical device [that] actually received the traffic, instead
of having the encapsulating device hide that information."
When the bonding device is just one level above the physical device, the two meanings happen to
match the same device, by chance.
So, currently, a bonding device cannot stack properly on top of anything but physical devices. It
might not be a problem today, but may change in the future...
Nicolas.
^ permalink raw reply
* TX VLAN acceleration on bridges broken in 2.6.37?
From: Jan Niehusmann @ 2011-02-21 23:29 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
With the following configuration, sending vlan tagged traffic from a
bridged interface doesn't work in 2.6.37.
The same configuration does work with 2.6.36:
- bridge br0 with physical interface eth0
- eth0 being an e1000e device (don't know if that's important)
- vlan interface br0.10
- (on 2.6.37) tx vlan acceleration active on br0 (default)
Networking on br0.10 doesn't work, and tcpdump on eth0 shows packets
sent on br0.10 as untagged, instead of vlan 10 tagged.
After turning vlan tx offloading off with 'ethtool -K br0 txvlan off',
everything works as expected, again.
The workaround is made permanent by reverting "bridge: Add support for
TX vlan offload.", 361ff8a6cf90d62c0071b7e532e37369bfd3ae77, turning
of the feature on bridges completely.
Jan
^ permalink raw reply
* RPS runs with multiqueue NIC
From: Jon Zhou @ 2011-02-22 3:07 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi
What will happen if RPS runs on kernel 2.6.36.4 machine where a multiqueue NIC intel x520 installed
Will it decrease or improve performance?
rui
^ permalink raw reply
* why all packets have same queue no when rps enabled?
From: Jon Zhou @ 2011-02-22 4:07 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi
I expect each incoming packet will have a different queue no. when I enabled RPS on kernel 2.6.36.4
cat /sys/class/net/eth4/queues/rx-0/rps_cpus
00000000,000000ff
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12 CPU13 CPU14 CPU15 CPU16
CPU17 CPU18 CPU19 CPU20 CPU21 CPU22 CPU23 CPU24 CPU25 CPU26 CPU27 CPU28 CPU29 CPU30 CPU31
HI: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
TIMER: 6027512 710165 2623243 542768 427807 217424 192940 217043 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
NET_TX: 1365741 59 750957 0 171 0 3 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
NET_RX: 40465750 11140803 8545859 14417762 8913471 12298691 14216845 3348431 < ---- indeed spread across cpus
I manually disable RSS on the intel X520 multiqueue supported NIC.
Cat /proc/interrupts
87: 21348294 0 0 0 0 0 0 0 PCI-MSI-edge eth4-rx-0
88: 38394 0 0 0 0 0 0 0 PCI-MSI-edge eth4-tx-0
When I tried the below program to filter packet by queue no.I got these results:
struct sock_filter BPF_code[]= {
{ 0x28,0,0,SKF_AD_OFF+SKF_AD_QUEUE},
{ 0x15, 0, 1, 0x00000001 },
{ 0x6, 0, 0, 0x0000ffff },
{ 0x6, 0, 0, 0x00000000 }
};
struct sock_fprog Filter;
Filter.len = 4;//15;
Filter.filter = BPF_code;
if ( (sock=socket(PF_PACKET, SOCK_RAW, htons(ETH_P_IP)))<0) {
perror("socket");
exit(1);
}
/* Set the network card in promiscuos mode */
strncpy(ethreq.ifr_name,"eth4",IFNAMSIZ);
if (ioctl(sock,SIOCGIFFLAGS,ðreq)==-1) {
perror("ioctl");
close(sock);
exit(1);
}
ethreq.ifr_flags|=IFF_PROMISC;
if (ioctl(sock,SIOCSIFFLAGS,ðreq)==-1) {
perror("ioctl");
close(sock);
exit(1);
}
/* Attach the filter to the socket */
if(setsockopt(sock, SOL_SOCKET, SO_ATTACH_FILTER,&Filter, sizeof(Filter))<0){
perror("setsockopt");
close(sock);
exit(1);
}
static int count = 0;
while (1) {
printf("#%d----------\n",count++);
n = recvfrom(sock,buffer,2048,0,NULL,NULL);
printf("%d bytes read\n",n);
...
}
Looks almost all packets fall at same queue?
Will RPS allocate queue no for each packet? and what hash algorithm rps used? (is it Toeplitz hash algorithm?)
jon
^ permalink raw reply
* Re: why all packets have same queue no when rps enabled?
From: Eric Dumazet @ 2011-02-22 5:41 UTC (permalink / raw)
To: Jon Zhou; +Cc: netdev@vger.kernel.org
In-Reply-To: <4A6A2125329CFD4D8CC40C9E8ABCAB9F24D3DE6D0C@MILEXCH2.ds.jdsu.net>
Le lundi 21 février 2011 à 20:07 -0800, Jon Zhou a écrit :
> Hi
>
> I expect each incoming packet will have a different queue no. when I enabled RPS on kernel 2.6.36.4
>
> cat /sys/class/net/eth4/queues/rx-0/rps_cpus
> 00000000,000000ff
>
> CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12 CPU13 CPU14 CPU15 CPU16
> CPU17 CPU18 CPU19 CPU20 CPU21 CPU22 CPU23 CPU24 CPU25 CPU26 CPU27 CPU28 CPU29 CPU30 CPU31
> HI: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> TIMER: 6027512 710165 2623243 542768 427807 217424 192940 217043 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> NET_TX: 1365741 59 750957 0 171 0 3 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> NET_RX: 40465750 11140803 8545859 14417762 8913471 12298691 14216845 3348431 < ---- indeed spread across cpus
>
>
> I manually disable RSS on the intel X520 multiqueue supported NIC.
> Cat /proc/interrupts
>
> 87: 21348294 0 0 0 0 0 0 0 PCI-MSI-edge eth4-rx-0
> 88: 38394 0 0 0 0 0 0 0 PCI-MSI-edge eth4-tx-0
>
>
>
> When I tried the below program to filter packet by queue no.I got these results:
>
> struct sock_filter BPF_code[]= {
> { 0x28,0,0,SKF_AD_OFF+SKF_AD_QUEUE},
> { 0x15, 0, 1, 0x00000001 },
> { 0x6, 0, 0, 0x0000ffff },
> { 0x6, 0, 0, 0x00000000 }
> };
>
> struct sock_fprog Filter;
>
> Filter.len = 4;//15;
> Filter.filter = BPF_code;
>
> if ( (sock=socket(PF_PACKET, SOCK_RAW, htons(ETH_P_IP)))<0) {
> perror("socket");
> exit(1);
> }
>
> /* Set the network card in promiscuos mode */
> strncpy(ethreq.ifr_name,"eth4",IFNAMSIZ);
> if (ioctl(sock,SIOCGIFFLAGS,ðreq)==-1) {
> perror("ioctl");
> close(sock);
> exit(1);
> }
> ethreq.ifr_flags|=IFF_PROMISC;
> if (ioctl(sock,SIOCSIFFLAGS,ðreq)==-1) {
> perror("ioctl");
> close(sock);
> exit(1);
> }
>
> /* Attach the filter to the socket */
> if(setsockopt(sock, SOL_SOCKET, SO_ATTACH_FILTER,&Filter, sizeof(Filter))<0){
> perror("setsockopt");
> close(sock);
> exit(1);
> }
> static int count = 0;
> while (1) {
> printf("#%d----------\n",count++);
> n = recvfrom(sock,buffer,2048,0,NULL,NULL);
> printf("%d bytes read\n",n);
> ...
> }
>
>
> Looks almost all packets fall at same queue?
> Will RPS allocate queue no for each packet? and what hash algorithm rps used? (is it Toeplitz hash algorithm?)
>
I believe you are mistaken.
RPS is not there to spread load on _all_ cpus, but to use a hash
function so that all packets of a given flow are directed to a given
cpu.
If you receive 1.000.000 packets of the same flow, they all are
delivered to one CPU.
^ permalink raw reply
* Re: RPS runs with multiqueue NIC
From: Eric Dumazet @ 2011-02-22 5:46 UTC (permalink / raw)
To: Jon Zhou; +Cc: netdev@vger.kernel.org
In-Reply-To: <4A6A2125329CFD4D8CC40C9E8ABCAB9F24D3DE6CC5@MILEXCH2.ds.jdsu.net>
Le lundi 21 février 2011 à 19:07 -0800, Jon Zhou a écrit :
> Hi
>
> What will happen if RPS runs on kernel 2.6.36.4 machine where a multiqueue NIC intel x520 installed
> Will it decrease or improve performance?
It depends on the workload.
For typical TCP flows, hardware multiqueue is generally better,
especially if the NIC supports the ethtool -X command (so that you can
tune effective number of cpus dedicated to the softirq processing).
Packet are delivered directly to the CPU target, without taking an extra
IPI.
For UDP workloads, adding RPS might be a win, because many NIC dont take
into account ports numbers in their hash computation, while
net/core/dev.c hash function does. If you receive trafic coming from a
single remote machine, RPS helps to spread flows between several cpus.
^ permalink raw reply
* RE: why all packets have same queue no when rps enabled?
From: Jon Zhou @ 2011-02-22 5:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <1298353270.3360.1.camel@edumazet-laptop>
> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: Tuesday, February 22, 2011 1:41 PM
> To: Jon Zhou
> Cc: netdev@vger.kernel.org
> Subject: Re: why all packets have same queue no when rps enabled?
>
> Le lundi 21 février 2011 à 20:07 -0800, Jon Zhou a écrit :
> > Hi
> >
> > I expect each incoming packet will have a different queue no. when I
> enabled RPS on kernel 2.6.36.4
> >
> > cat /sys/class/net/eth4/queues/rx-0/rps_cpus
> > 00000000,000000ff
> >
> > CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
> CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12
> CPU13 CPU14 CPU15 CPU16
> > CPU17 CPU18 CPU19 CPU20 CPU21 CPU22
> CPU23 CPU24 CPU25 CPU26 CPU27 CPU28 CPU29
> CPU30 CPU31
> > HI: 0 0 0 0 0
> 0 0 0 0 0 0 0
> 0 0 0 0 0
> > 0 0 0 0 0 0
> 0 0 0 0 0 0 0
> 0 0
> > TIMER: 6027512 710165 2623243 542768 427807
> 217424 192940 217043 0 0 0
> 0 0 0 0 0 0
> > 0 0 0 0 0 0
> 0 0 0 0 0 0 0
> 0 0
> > NET_TX: 1365741 59 750957 0 171
> 0 3 0 0 0 0 0
> 0 0 0 0 0
> > 0 0 0 0 0 0
> 0 0 0 0 0 0 0
> 0 0
> > NET_RX: 40465750 11140803 8545859 14417762 8913471
> 12298691 14216845 3348431 < ---- indeed spread across cpus
> >
> >
> > I manually disable RSS on the intel X520 multiqueue supported NIC.
> > Cat /proc/interrupts
> >
> > 87: 21348294 0 0 0 0
> 0 0 0 PCI-MSI-edge eth4-rx-0
> > 88: 38394 0 0 0 0
> 0 0 0 PCI-MSI-edge eth4-tx-0
> >
> >
> >
> > When I tried the below program to filter packet by queue no.I got
> these results:
> >
> > struct sock_filter BPF_code[]= {
> > { 0x28,0,0,SKF_AD_OFF+SKF_AD_QUEUE},
> > { 0x15, 0, 1, 0x00000001 },
> > { 0x6, 0, 0, 0x0000ffff },
> > { 0x6, 0, 0, 0x00000000 }
> > };
> >
> > struct sock_fprog Filter;
> >
> > Filter.len = 4;//15;
> > Filter.filter = BPF_code;
> >
> > if ( (sock=socket(PF_PACKET, SOCK_RAW, htons(ETH_P_IP)))<0) {
> > perror("socket");
> > exit(1);
> > }
> >
> > /* Set the network card in promiscuos mode */
> > strncpy(ethreq.ifr_name,"eth4",IFNAMSIZ);
> > if (ioctl(sock,SIOCGIFFLAGS,ðreq)==-1) {
> > perror("ioctl");
> > close(sock);
> > exit(1);
> > }
> > ethreq.ifr_flags|=IFF_PROMISC;
> > if (ioctl(sock,SIOCSIFFLAGS,ðreq)==-1) {
> > perror("ioctl");
> > close(sock);
> > exit(1);
> > }
> >
> > /* Attach the filter to the socket */
> > if(setsockopt(sock, SOL_SOCKET, SO_ATTACH_FILTER,&Filter,
> sizeof(Filter))<0){
> > perror("setsockopt");
> > close(sock);
> > exit(1);
> > }
> > static int count = 0;
> > while (1) {
> > printf("#%d----------\n",count++);
> > n = recvfrom(sock,buffer,2048,0,NULL,NULL);
> > printf("%d bytes read\n",n);
> > ...
> > }
> >
> >
> > Looks almost all packets fall at same queue?
> > Will RPS allocate queue no for each packet? and what hash algorithm
> rps used? (is it Toeplitz hash algorithm?)
> >
>
> I believe you are mistaken.
>
> RPS is not there to spread load on _all_ cpus, but to use a hash
> function so that all packets of a given flow are directed to a given
> cpu.
>
> If you receive 1.000.000 packets of the same flow, they all are
> delivered to one CPU.
>
>
With RSS supported NIC, I saw packet#0,1,2,3,~packet#7 will be delivered to different queue, but after RSS disabled and RPS turn on, all these packet will be allocated same queue no(I used the above filter program to find that)
Is there any fault in the filter program?
^ permalink raw reply
* RE: why all packets have same queue no when rps enabled?
From: Eric Dumazet @ 2011-02-22 6:13 UTC (permalink / raw)
To: Jon Zhou; +Cc: netdev@vger.kernel.org
In-Reply-To: <4A6A2125329CFD4D8CC40C9E8ABCAB9F24D3DE6D51@MILEXCH2.ds.jdsu.net>
Le lundi 21 février 2011 à 21:56 -0800, Jon Zhou a écrit :
>
> > -----Original Message-----
> > From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> > Sent: Tuesday, February 22, 2011 1:41 PM
> > To: Jon Zhou
> > Cc: netdev@vger.kernel.org
> > Subject: Re: why all packets have same queue no when rps enabled?
> >
> > Le lundi 21 février 2011 à 20:07 -0800, Jon Zhou a écrit :
> > > Hi
> > >
> > > I expect each incoming packet will have a different queue no. when I
> > enabled RPS on kernel 2.6.36.4
> > >
> > > cat /sys/class/net/eth4/queues/rx-0/rps_cpus
> > > 00000000,000000ff
> > >
> > > CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
> > CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12
> > CPU13 CPU14 CPU15 CPU16
> > > CPU17 CPU18 CPU19 CPU20 CPU21 CPU22
> > CPU23 CPU24 CPU25 CPU26 CPU27 CPU28 CPU29
> > CPU30 CPU31
> > > HI: 0 0 0 0 0
> > 0 0 0 0 0 0 0
> > 0 0 0 0 0
> > > 0 0 0 0 0 0
> > 0 0 0 0 0 0 0
> > 0 0
> > > TIMER: 6027512 710165 2623243 542768 427807
> > 217424 192940 217043 0 0 0
> > 0 0 0 0 0 0
> > > 0 0 0 0 0 0
> > 0 0 0 0 0 0 0
> > 0 0
> > > NET_TX: 1365741 59 750957 0 171
> > 0 3 0 0 0 0 0
> > 0 0 0 0 0
> > > 0 0 0 0 0 0
> > 0 0 0 0 0 0 0
> > 0 0
> > > NET_RX: 40465750 11140803 8545859 14417762 8913471
> > 12298691 14216845 3348431 < ---- indeed spread across cpus
> > >
> > >
> > > I manually disable RSS on the intel X520 multiqueue supported NIC.
> > > Cat /proc/interrupts
> > >
> > > 87: 21348294 0 0 0 0
> > 0 0 0 PCI-MSI-edge eth4-rx-0
> > > 88: 38394 0 0 0 0
> > 0 0 0 PCI-MSI-edge eth4-tx-0
> > >
> > >
> > >
> > > When I tried the below program to filter packet by queue no.I got
> > these results:
> > >
> > > struct sock_filter BPF_code[]= {
> > > { 0x28,0,0,SKF_AD_OFF+SKF_AD_QUEUE},
> > > { 0x15, 0, 1, 0x00000001 },
> > > { 0x6, 0, 0, 0x0000ffff },
> > > { 0x6, 0, 0, 0x00000000 }
> > > };
> > >
> > > struct sock_fprog Filter;
> > >
> > > Filter.len = 4;//15;
> > > Filter.filter = BPF_code;
> > >
> > > if ( (sock=socket(PF_PACKET, SOCK_RAW, htons(ETH_P_IP)))<0) {
> > > perror("socket");
> > > exit(1);
> > > }
> > >
> > > /* Set the network card in promiscuos mode */
> > > strncpy(ethreq.ifr_name,"eth4",IFNAMSIZ);
> > > if (ioctl(sock,SIOCGIFFLAGS,ðreq)==-1) {
> > > perror("ioctl");
> > > close(sock);
> > > exit(1);
> > > }
> > > ethreq.ifr_flags|=IFF_PROMISC;
> > > if (ioctl(sock,SIOCSIFFLAGS,ðreq)==-1) {
> > > perror("ioctl");
> > > close(sock);
> > > exit(1);
> > > }
> > >
> > > /* Attach the filter to the socket */
> > > if(setsockopt(sock, SOL_SOCKET, SO_ATTACH_FILTER,&Filter,
> > sizeof(Filter))<0){
> > > perror("setsockopt");
> > > close(sock);
> > > exit(1);
> > > }
> > > static int count = 0;
> > > while (1) {
> > > printf("#%d----------\n",count++);
> > > n = recvfrom(sock,buffer,2048,0,NULL,NULL);
> > > printf("%d bytes read\n",n);
> > > ...
> > > }
> > >
> > >
> > > Looks almost all packets fall at same queue?
> > > Will RPS allocate queue no for each packet? and what hash algorithm
> > rps used? (is it Toeplitz hash algorithm?)
> > >
> >
> > I believe you are mistaken.
> >
> > RPS is not there to spread load on _all_ cpus, but to use a hash
> > function so that all packets of a given flow are directed to a given
> > cpu.
> >
> > If you receive 1.000.000 packets of the same flow, they all are
> > delivered to one CPU.
> >
> >
> With RSS supported NIC, I saw packet#0,1,2,3,~packet#7 will be delivered to different queue, but after RSS disabled and RPS turn on, all these packet will be allocated same queue no(I used the above filter program to find that)
> Is there any fault in the filter program?
>
I dont know...
The easy way to find out is to actually do "cat /proc/net/softnet_stat"
Since the last column is the number of time a cpu was given a packet by
another cpu (RPS or RFS action)
^ permalink raw reply
* Re: [PATCH ethtool 5/5] ethtool: Add --version option
From: Stephen Hemminger @ 2011-02-22 6:16 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1298315959.2608.73.camel@bwh-desktop>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> --- ethtool.8.in | 5 +++++
> ethtool.c | 6 ++++++
> 2 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/ethtool.8.in b/ethtool.8.in
> index 133825b..8b04335 100644
> --- a/ethtool.8.in
> +++ b/ethtool.8.in
> @@ -100,6 +100,8 @@ ethtool \- query or control network driver and
> hardware settings
>
> .B ethtool \-h|\-\-help
>
> +.B ethtool \-\-version
> + .B ethtool \-a|\-\-show\-pause
> .I ethX
>
> @@ -310,6 +312,9 @@ settings of the specified device.
> .B \-h \-\-help
> Shows a short help message.
> .TP +.B \-\-version
> +Shows the ethtool version number.
> +.TP .B \-a \-\-show\-pause
> Queries the specified Ethernet device for pause parameter information.
> .TP diff --git a/ethtool.c b/ethtool.c
> index 32a97f6..e9cb2c9 100644
> --- a/ethtool.c
> +++ b/ethtool.c
> @@ -115,6 +115,7 @@ static int do_permaddr(int fd, struct ifreq *ifr);
> static int send_ioctl(int fd, struct ifreq *ifr);
>
> static enum {
> + MODE_VERSION = -2,
> MODE_HELP = -1,
> MODE_GSET=0, MODE_SSET,
> @@ -264,6 +265,7 @@ static struct option {
> { "-P", "--show-permaddr", MODE_PERMADDR,
> "Show permanent hardware address" },
> { "-h", "--help", MODE_HELP, "Show this help" },
> + { NULL, "--version", MODE_VERSION, "Show version number" },
The standard convention is to use -V for short form of version option.
^ permalink raw reply
* [PATCH 1/5] r8169: Correct settings of rtl8102e
From: Hayes Wang @ 2011-02-22 6:41 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
Adjust and remove certain settings of RTL8102E which are for previous chips.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 20 ++++++--------------
1 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 469ab0b..3630dd7 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -3042,7 +3042,7 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
goto err_out_mwi_2;
}
- tp->cp_cmd = PCIMulRW | RxChkSum;
+ tp->cp_cmd = RxChkSum;
if ((sizeof(dma_addr_t) > 4) &&
!pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) && use_dac) {
@@ -3847,8 +3847,7 @@ static void rtl_hw_start_8168(struct net_device *dev)
Cxpl_dbg_sel | \
ASF | \
PktCntrDisable | \
- PCIDAC | \
- PCIMulRW)
+ Mac_dbgo_sel)
static void rtl_hw_start_8102e_1(void __iomem *ioaddr, struct pci_dev *pdev)
{
@@ -3878,8 +3877,6 @@ static void rtl_hw_start_8102e_1(void __iomem *ioaddr, struct pci_dev *pdev)
if ((cfg1 & LEDS0) && (cfg1 & LEDS1))
RTL_W8(Config1, cfg1 & ~LEDS0);
- RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) & ~R810X_CPCMD_QUIRK_MASK);
-
rtl_ephy_init(ioaddr, e_info_8102e_1, ARRAY_SIZE(e_info_8102e_1));
}
@@ -3891,8 +3888,6 @@ static void rtl_hw_start_8102e_2(void __iomem *ioaddr, struct pci_dev *pdev)
RTL_W8(Config1, MEMMAP | IOMAP | VPD | PMEnable);
RTL_W8(Config3, RTL_R8(Config3) & ~Beacon_en);
-
- RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) & ~R810X_CPCMD_QUIRK_MASK);
}
static void rtl_hw_start_8102e_3(void __iomem *ioaddr, struct pci_dev *pdev)
@@ -3918,6 +3913,8 @@ static void rtl_hw_start_8101(struct net_device *dev)
}
}
+ RTL_W8(Cfg9346, Cfg9346_Unlock);
+
switch (tp->mac_version) {
case RTL_GIGA_MAC_VER_07:
rtl_hw_start_8102e_1(ioaddr, pdev);
@@ -3932,14 +3929,13 @@ static void rtl_hw_start_8101(struct net_device *dev)
break;
}
- RTL_W8(Cfg9346, Cfg9346_Unlock);
+ RTL_W8(Cfg9346, Cfg9346_Lock);
RTL_W8(MaxTxPacketSize, TxPacketMax);
rtl_set_rx_max_size(ioaddr, rx_buf_sz);
- tp->cp_cmd |= rtl_rw_cpluscmd(ioaddr) | PCIMulRW;
-
+ tp->cp_cmd &= ~R810X_CPCMD_QUIRK_MASK;
RTL_W16(CPlusCmd, tp->cp_cmd);
RTL_W16(IntrMitigate, 0x0000);
@@ -3949,14 +3945,10 @@ static void rtl_hw_start_8101(struct net_device *dev)
RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
rtl_set_rx_tx_config_registers(tp);
- RTL_W8(Cfg9346, Cfg9346_Lock);
-
RTL_R8(IntrMask);
rtl_set_rx_mode(dev);
- RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
-
RTL_W16(MultiIntr, RTL_R16(MultiIntr) & 0xf000);
RTL_W16(IntrMask, tp->intr_event);
--
1.7.3.2
^ permalink raw reply related
* [PATCH 2/5] r8169: Support RTL8105E
From: Hayes Wang @ 2011-02-22 6:41 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
In-Reply-To: <1298356917-486-1-git-send-email-hayeswang@realtek.com>
Support the new chips for RTL8105E
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 90 insertions(+), 2 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 3630dd7..5d89f89 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -36,6 +36,7 @@
#define FIRMWARE_8168D_1 "rtl_nic/rtl8168d-1.fw"
#define FIRMWARE_8168D_2 "rtl_nic/rtl8168d-2.fw"
+#define FIRMWARE_8105E_1 "rtl_nic/rtl8105e-1.fw"
#ifdef RTL8169_DEBUG
#define assert(expr) \
@@ -123,6 +124,8 @@ enum mac_version {
RTL_GIGA_MAC_VER_26 = 0x1a, // 8168D
RTL_GIGA_MAC_VER_27 = 0x1b, // 8168DP
RTL_GIGA_MAC_VER_28 = 0x1c, // 8168DP
+ RTL_GIGA_MAC_VER_29 = 0x1d, // 8105E
+ RTL_GIGA_MAC_VER_30 = 0x1e, // 8105E
};
#define _R(NAME,MAC,MASK) \
@@ -160,7 +163,9 @@ static const struct {
_R("RTL8168d/8111d", RTL_GIGA_MAC_VER_25, 0xff7e1880), // PCI-E
_R("RTL8168d/8111d", RTL_GIGA_MAC_VER_26, 0xff7e1880), // PCI-E
_R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_27, 0xff7e1880), // PCI-E
- _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_28, 0xff7e1880) // PCI-E
+ _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_28, 0xff7e1880), // PCI-E
+ _R("RTL8105e", RTL_GIGA_MAC_VER_29, 0xff7e1880), // PCI-E
+ _R("RTL8105e", RTL_GIGA_MAC_VER_30, 0xff7e1880) // PCI-E
};
#undef _R
@@ -267,9 +272,15 @@ enum rtl8168_8101_registers {
#define EPHYAR_REG_MASK 0x1f
#define EPHYAR_REG_SHIFT 16
#define EPHYAR_DATA_MASK 0xffff
+ DLLPR = 0xd0,
+#define PM_SWITCH (1 << 6)
DBG_REG = 0xd1,
#define FIX_NAK_1 (1 << 4)
#define FIX_NAK_2 (1 << 3)
+ TWSI = 0xd2,
+ MCU = 0xd3,
+#define EN_NDP (1 << 3)
+#define EN_OOB_RESET (1 << 2)
EFUSEAR = 0xdc,
#define EFUSEAR_FLAG 0x80000000
#define EFUSEAR_WRITE_CMD 0x80000000
@@ -568,6 +579,7 @@ MODULE_LICENSE("GPL");
MODULE_VERSION(RTL8169_VERSION);
MODULE_FIRMWARE(FIRMWARE_8168D_1);
MODULE_FIRMWARE(FIRMWARE_8168D_2);
+MODULE_FIRMWARE(FIRMWARE_8105E_1);
static int rtl8169_open(struct net_device *dev);
static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
@@ -1143,7 +1155,9 @@ static int rtl8169_set_speed_xmii(struct net_device *dev,
(tp->mac_version != RTL_GIGA_MAC_VER_13) &&
(tp->mac_version != RTL_GIGA_MAC_VER_14) &&
(tp->mac_version != RTL_GIGA_MAC_VER_15) &&
- (tp->mac_version != RTL_GIGA_MAC_VER_16)) {
+ (tp->mac_version != RTL_GIGA_MAC_VER_16) &&
+ (tp->mac_version != RTL_GIGA_MAC_VER_29) &&
+ (tp->mac_version != RTL_GIGA_MAC_VER_30)) {
giga_ctrl |= ADVERTISE_1000FULL | ADVERTISE_1000HALF;
} else {
netif_info(tp, link, dev,
@@ -1559,6 +1573,9 @@ static void rtl8169_get_mac_version(struct rtl8169_private *tp,
{ 0x7c800000, 0x30000000, RTL_GIGA_MAC_VER_11 },
/* 8101 family. */
+ { 0x7cf00000, 0x40a00000, RTL_GIGA_MAC_VER_30 },
+ { 0x7cf00000, 0x40900000, RTL_GIGA_MAC_VER_29 },
+ { 0x7c800000, 0x40800000, RTL_GIGA_MAC_VER_30 },
{ 0x7cf00000, 0x34a00000, RTL_GIGA_MAC_VER_09 },
{ 0x7cf00000, 0x24a00000, RTL_GIGA_MAC_VER_09 },
{ 0x7cf00000, 0x34900000, RTL_GIGA_MAC_VER_08 },
@@ -2435,6 +2452,33 @@ static void rtl8102e_hw_phy_config(struct rtl8169_private *tp)
rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
}
+static void rtl8105e_hw_phy_config(struct rtl8169_private *tp)
+{
+ static const struct phy_reg phy_reg_init[] = {
+ { 0x1f, 0x0005 },
+ { 0x1a, 0x0000 },
+ { 0x1f, 0x0000 },
+
+ { 0x1f, 0x0004 },
+ { 0x1c, 0x0000 },
+ { 0x1f, 0x0000 },
+
+ { 0x1f, 0x0001 },
+ { 0x15, 0x7701 },
+ { 0x1f, 0x0000 }
+ };
+
+ /* Disable ALDPS before ram code */
+ rtl_writephy(tp, 0x1f, 0x0000);
+ rtl_writephy(tp, 0x18, 0x0310);
+ msleep(100);
+
+ if (rtl_apply_firmware(tp, FIRMWARE_8105E_1) < 0)
+ netif_warn(tp, probe, tp->dev, "unable to apply firmware patch\n");
+
+ rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
+}
+
static void rtl_hw_phy_config(struct net_device *dev)
{
struct rtl8169_private *tp = netdev_priv(dev);
@@ -2502,6 +2546,10 @@ static void rtl_hw_phy_config(struct net_device *dev)
case RTL_GIGA_MAC_VER_28:
rtl8168d_4_hw_phy_config(tp);
break;
+ case RTL_GIGA_MAC_VER_29:
+ case RTL_GIGA_MAC_VER_30:
+ rtl8105e_hw_phy_config(tp);
+ break;
default:
break;
@@ -2940,6 +2988,8 @@ static void __devinit rtl_init_pll_power_ops(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_09:
case RTL_GIGA_MAC_VER_10:
case RTL_GIGA_MAC_VER_16:
+ case RTL_GIGA_MAC_VER_29:
+ case RTL_GIGA_MAC_VER_30:
ops->down = r810x_pll_power_down;
ops->up = r810x_pll_power_up;
break;
@@ -3897,6 +3947,37 @@ static void rtl_hw_start_8102e_3(void __iomem *ioaddr, struct pci_dev *pdev)
rtl_ephy_write(ioaddr, 0x03, 0xc2f9);
}
+static void rtl_hw_start_8105e_1(void __iomem *ioaddr, struct pci_dev *pdev)
+{
+ static const struct ephy_info e_info_8105e_1[] = {
+ { 0x07, 0, 0x4000 },
+ { 0x19, 0, 0x0200 },
+ { 0x19, 0, 0x0020 },
+ { 0x1e, 0, 0x2000 },
+ { 0x03, 0, 0x0001 },
+ { 0x19, 0, 0x0100 },
+ { 0x19, 0, 0x0004 },
+ { 0x0a, 0, 0x0020 }
+ };
+
+ /* Force LAN exit from ASPM if Rx/Tx are not idel */
+ RTL_W32(FuncEvent, RTL_R32(FuncEvent) | 0x002800);
+
+ /* disable Early Tally Counter */
+ RTL_W32(FuncEvent, RTL_R32(FuncEvent) & ~0x010000);
+
+ RTL_W8(MCU, RTL_R8(MCU) | EN_NDP | EN_OOB_RESET);
+ RTL_W8(DLLPR, RTL_R8(DLLPR) | PM_SWITCH);
+
+ rtl_ephy_init(ioaddr, e_info_8105e_1, ARRAY_SIZE(e_info_8105e_1));
+}
+
+static void rtl_hw_start_8105e_2(void __iomem *ioaddr, struct pci_dev *pdev)
+{
+ rtl_hw_start_8105e_1(ioaddr, pdev);
+ rtl_ephy_write(ioaddr, 0x1e, rtl_ephy_read(ioaddr, 0x1e) | 0x8000);
+}
+
static void rtl_hw_start_8101(struct net_device *dev)
{
struct rtl8169_private *tp = netdev_priv(dev);
@@ -3927,6 +4008,13 @@ static void rtl_hw_start_8101(struct net_device *dev)
case RTL_GIGA_MAC_VER_09:
rtl_hw_start_8102e_2(ioaddr, pdev);
break;
+
+ case RTL_GIGA_MAC_VER_29:
+ rtl_hw_start_8105e_1(ioaddr, pdev);
+ break;
+ case RTL_GIGA_MAC_VER_30:
+ rtl_hw_start_8105e_2(ioaddr, pdev);
+ break;
}
RTL_W8(Cfg9346, Cfg9346_Lock);
--
1.7.3.2
^ permalink raw reply related
* [PATCH 3/5] r8169: fix the wrong parameter of point address
From: Hayes Wang @ 2011-02-22 6:41 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
In-Reply-To: <1298356917-486-1-git-send-email-hayeswang@realtek.com>
Correct the parameter of rtl8168_oob_notify. It results in the
wrong point address and influences RTL8168DP.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 5d89f89..ff66aa6 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -629,8 +629,9 @@ static void ocp_write(struct rtl8169_private *tp, u8 mask, u16 reg, u32 data)
}
}
-static void rtl8168_oob_notify(void __iomem *ioaddr, u8 cmd)
+static void rtl8168_oob_notify(struct rtl8169_private *tp, u8 cmd)
{
+ void __iomem *ioaddr = tp->mmio_addr;
int i;
RTL_W8(ERIDR, cmd);
@@ -642,7 +643,7 @@ static void rtl8168_oob_notify(void __iomem *ioaddr, u8 cmd)
break;
}
- ocp_write(ioaddr, 0x1, 0x30, 0x00000001);
+ ocp_write(tp, 0x1, 0x30, 0x00000001);
}
#define OOB_CMD_RESET 0x00
--
1.7.3.2
^ permalink raw reply related
* [PATCH 4/5] r8169: adjust the code of RTL8168DP
From: Hayes Wang @ 2011-02-22 6:41 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
In-Reply-To: <1298356917-486-1-git-send-email-hayeswang@realtek.com>
Adjust the code of power up and down functions for RTL8168DP.
Skip these functions when DASH is enable.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 17 ++++++++++++++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index ff66aa6..9e7e3b3 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -2917,8 +2917,11 @@ static void r8168_pll_power_down(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
- if (tp->mac_version == RTL_GIGA_MAC_VER_27)
+ if (((tp->mac_version == RTL_GIGA_MAC_VER_27) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_28)) &&
+ (ocp_read(tp, 0x0f, 0x0010) & 0x00008000)) {
return;
+ }
if (((tp->mac_version == RTL_GIGA_MAC_VER_23) ||
(tp->mac_version == RTL_GIGA_MAC_VER_24)) &&
@@ -2940,6 +2943,8 @@ static void r8168_pll_power_down(struct rtl8169_private *tp)
switch (tp->mac_version) {
case RTL_GIGA_MAC_VER_25:
case RTL_GIGA_MAC_VER_26:
+ case RTL_GIGA_MAC_VER_27:
+ case RTL_GIGA_MAC_VER_28:
RTL_W8(PMCH, RTL_R8(PMCH) & ~0x80);
break;
}
@@ -2949,12 +2954,17 @@ static void r8168_pll_power_up(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
- if (tp->mac_version == RTL_GIGA_MAC_VER_27)
+ if (((tp->mac_version == RTL_GIGA_MAC_VER_27) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_28)) &&
+ (ocp_read(tp, 0x0f, 0x0010) & 0x00008000)) {
return;
+ }
switch (tp->mac_version) {
case RTL_GIGA_MAC_VER_25:
case RTL_GIGA_MAC_VER_26:
+ case RTL_GIGA_MAC_VER_27:
+ case RTL_GIGA_MAC_VER_28:
RTL_W8(PMCH, RTL_R8(PMCH) | 0x80);
break;
}
@@ -3369,7 +3379,8 @@ static void rtl8169_hw_reset(struct rtl8169_private *tp)
/* Disable interrupts */
rtl8169_irq_mask_and_ack(ioaddr);
- if (tp->mac_version == RTL_GIGA_MAC_VER_28) {
+ if (tp->mac_version == RTL_GIGA_MAC_VER_27 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_28) {
while (RTL_R8(TxPoll) & NPQ)
udelay(20);
--
1.7.3.2
^ permalink raw reply related
* [PATCH 5/5] r8169: adjust rtl8169_set_speed_xmii function
From: Hayes Wang @ 2011-02-22 6:41 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
In-Reply-To: <1298356917-486-1-git-send-email-hayeswang@realtek.com>
Adjust code of rtl8169_set_speed_xmii function and remove part
codes which have done in rtl_pll_power_up function.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 16 ++--------------
1 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 9e7e3b3..8c85545 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1137,6 +1137,8 @@ static int rtl8169_set_speed_xmii(struct net_device *dev,
struct rtl8169_private *tp = netdev_priv(dev);
int giga_ctrl, bmcr;
+ rtl_writephy(tp, 0x1f, 0x0000);
+
if (autoneg == AUTONEG_ENABLE) {
int auto_nego;
@@ -1167,18 +1169,6 @@ static int rtl8169_set_speed_xmii(struct net_device *dev,
bmcr = BMCR_ANENABLE | BMCR_ANRESTART;
- if ((tp->mac_version == RTL_GIGA_MAC_VER_11) ||
- (tp->mac_version == RTL_GIGA_MAC_VER_12) ||
- (tp->mac_version >= RTL_GIGA_MAC_VER_17)) {
- /*
- * Wake up the PHY.
- * Vendor specific (0x1f) and reserved (0x0e) MII
- * registers.
- */
- rtl_writephy(tp, 0x1f, 0x0000);
- rtl_writephy(tp, 0x0e, 0x0000);
- }
-
rtl_writephy(tp, MII_ADVERTISE, auto_nego);
rtl_writephy(tp, MII_CTRL1000, giga_ctrl);
} else {
@@ -1193,8 +1183,6 @@ static int rtl8169_set_speed_xmii(struct net_device *dev,
if (duplex == DUPLEX_FULL)
bmcr |= BMCR_FULLDPLX;
-
- rtl_writephy(tp, 0x1f, 0x0000);
}
tp->phy_1000_ctrl_reg = giga_ctrl;
--
1.7.3.2
^ permalink raw reply related
* Re: [v3 RFC PATCH 0/4] Implement multiqueue virtio-net
From: Simon Horman @ 2011-02-22 7:47 UTC (permalink / raw)
To: Krishna Kumar
Cc: rusty, davem, mst, arnd, eric.dumazet, netdev, avi, anthony, kvm
In-Reply-To: <20101020085452.15579.76002.sendpatchset@krkumar2.in.ibm.com>
On Wed, Oct 20, 2010 at 02:24:52PM +0530, Krishna Kumar wrote:
> Following set of patches implement transmit MQ in virtio-net. Also
> included is the user qemu changes. MQ is disabled by default unless
> qemu specifies it.
Hi Krishna,
I have a few questions about the results below:
1. Are the (%) comparisons between non-mq and mq virtio?
2. Was UDP or TCP used?
3. What was the transmit size (-m option to netperf)?
Also, I'm interested to know what the status of these patches is.
Are you planing a fresh series?
>
> Changes from rev2:
> ------------------
> 1. Define (in virtio_net.h) the maximum send txqs; and use in
> virtio-net and vhost-net.
> 2. vi->sq[i] is allocated individually, resulting in cache line
> aligned sq[0] to sq[n]. Another option was to define
> 'send_queue' as:
> struct send_queue {
> struct virtqueue *svq;
> struct scatterlist tx_sg[MAX_SKB_FRAGS + 2];
> } ____cacheline_aligned_in_smp;
> and to statically allocate 'VIRTIO_MAX_SQ' of those. I hope
> the submitted method is preferable.
> 3. Changed vhost model such that vhost[0] handles RX and vhost[1-MAX]
> handles TX[0-n].
> 4. Further change TX handling such that vhost[0] handles both RX/TX
> for single stream case.
>
> Enabling MQ on virtio:
> -----------------------
> When following options are passed to qemu:
> - smp > 1
> - vhost=on
> - mq=on (new option, default:off)
> then #txqueues = #cpus. The #txqueues can be changed by using an
> optional 'numtxqs' option. e.g. for a smp=4 guest:
> vhost=on -> #txqueues = 1
> vhost=on,mq=on -> #txqueues = 4
> vhost=on,mq=on,numtxqs=2 -> #txqueues = 2
> vhost=on,mq=on,numtxqs=8 -> #txqueues = 8
>
>
> Performance (guest -> local host):
> -----------------------------------
> System configuration:
> Host: 8 Intel Xeon, 8 GB memory
> Guest: 4 cpus, 2 GB memory
> Test: Each test case runs for 60 secs, sum over three runs (except
> when number of netperf sessions is 1, which has 10 runs of 12 secs
> each). No tuning (default netperf) other than taskset vhost's to
> cpus 0-3. numtxqs=32 gave the best results though the guest had
> only 4 vcpus (I haven't tried beyond that).
>
> ______________ numtxqs=2, vhosts=3 ____________________
> #sessions BW% CPU% RCPU% SD% RSD%
> ________________________________________________________
> 1 4.46 -1.96 .19 -12.50 -6.06
> 2 4.93 -1.16 2.10 0 -2.38
> 4 46.17 64.77 33.72 19.51 -2.48
> 8 47.89 70.00 36.23 41.46 13.35
> 16 48.97 80.44 40.67 21.11 -5.46
> 24 49.03 78.78 41.22 20.51 -4.78
> 32 51.11 77.15 42.42 15.81 -6.87
> 40 51.60 71.65 42.43 9.75 -8.94
> 48 50.10 69.55 42.85 11.80 -5.81
> 64 46.24 68.42 42.67 14.18 -3.28
> 80 46.37 63.13 41.62 7.43 -6.73
> 96 46.40 63.31 42.20 9.36 -4.78
> 128 50.43 62.79 42.16 13.11 -1.23
> ________________________________________________________
> BW: 37.2%, CPU/RCPU: 66.3%,41.6%, SD/RSD: 11.5%,-3.7%
>
> ______________ numtxqs=8, vhosts=5 ____________________
> #sessions BW% CPU% RCPU% SD% RSD%
> ________________________________________________________
> 1 -.76 -1.56 2.33 0 3.03
> 2 17.41 11.11 11.41 0 -4.76
> 4 42.12 55.11 30.20 19.51 .62
> 8 54.69 80.00 39.22 24.39 -3.88
> 16 54.77 81.62 40.89 20.34 -6.58
> 24 54.66 79.68 41.57 15.49 -8.99
> 32 54.92 76.82 41.79 17.59 -5.70
> 40 51.79 68.56 40.53 15.31 -3.87
> 48 51.72 66.40 40.84 9.72 -7.13
> 64 51.11 63.94 41.10 5.93 -8.82
> 80 46.51 59.50 39.80 9.33 -4.18
> 96 47.72 57.75 39.84 4.20 -7.62
> 128 54.35 58.95 40.66 3.24 -8.63
> ________________________________________________________
> BW: 38.9%, CPU/RCPU: 63.0%,40.1%, SD/RSD: 6.0%,-7.4%
>
> ______________ numtxqs=16, vhosts=5 ___________________
> #sessions BW% CPU% RCPU% SD% RSD%
> ________________________________________________________
> 1 -1.43 -3.52 1.55 0 3.03
> 2 33.09 21.63 20.12 -10.00 -9.52
> 4 67.17 94.60 44.28 19.51 -11.80
> 8 75.72 108.14 49.15 25.00 -10.71
> 16 80.34 101.77 52.94 25.93 -4.49
> 24 70.84 93.12 43.62 27.63 -5.03
> 32 69.01 94.16 47.33 29.68 -1.51
> 40 58.56 63.47 25.91 -3.92 -25.85
> 48 61.16 74.70 34.88 .89 -22.08
> 64 54.37 69.09 26.80 -6.68 -30.04
> 80 36.22 22.73 -2.97 -8.25 -27.23
> 96 41.51 50.59 13.24 9.84 -16.77
> 128 48.98 38.15 6.41 -.33 -22.80
> ________________________________________________________
> BW: 46.2%, CPU/RCPU: 55.2%,18.8%, SD/RSD: 1.2%,-22.0%
>
> ______________ numtxqs=32, vhosts=5 ___________________
> # BW% CPU% RCPU% SD% RSD%
> ________________________________________________________
> 1 7.62 -38.03 -26.26 -50.00 -33.33
> 2 28.95 20.46 21.62 0 -7.14
> 4 84.05 60.79 45.74 -2.43 -12.42
> 8 86.43 79.57 50.32 15.85 -3.10
> 16 88.63 99.48 58.17 9.47 -13.10
> 24 74.65 80.87 41.99 -1.81 -22.89
> 32 63.86 59.21 23.58 -18.13 -36.37
> 40 64.79 60.53 22.23 -15.77 -35.84
> 48 49.68 26.93 .51 -36.40 -49.61
> 64 54.69 36.50 5.41 -26.59 -43.23
> 80 45.06 12.72 -13.25 -37.79 -52.08
> 96 40.21 -3.16 -24.53 -39.92 -52.97
> 128 36.33 -33.19 -43.66 -5.68 -20.49
> ________________________________________________________
> BW: 49.3%, CPU/RCPU: 15.5%,-8.2%, SD/RSD: -22.2%,-37.0%
>
>
> Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
> ---
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 3/5] r8169: fix the wrong parameter of point address
From: Francois Romieu @ 2011-02-22 8:00 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <1298356917-486-3-git-send-email-hayeswang@realtek.com>
Hayes Wang <hayeswang@realtek.com> :
> Correct the parameter of rtl8168_oob_notify. It results in the
> wrong point address and influences RTL8168DP.
Please send this one separately as a patch against current kernel
tree as it is clearly a bugfix. The remaining patches are probably
more -next material.
--
Ueimor
^ permalink raw reply
* Re: [PATCH 3/5] r8169: fix the wrong parameter of point address
From: Francois Romieu @ 2011-02-22 8:21 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <20110222080017.GA12453@electric-eye.fr.zoreil.com>
Francois Romieu <romieu@fr.zoreil.com> :
> Hayes Wang <hayeswang@realtek.com> :
> > Correct the parameter of rtl8168_oob_notify. It results in the
> > wrong point address and influences RTL8168DP.
>
> Please send this one separately as a patch against current kernel
> tree as it is clearly a bugfix. The remaining patches are probably
> more -next material.
Correct me if I am wrong:
- #3 and #1 are bugfixes
- can you specify if #4 and #5 are either bugfixes, optimizations or cleanups ?
- #2 adds support for a new chipset
--
Ueimor
^ permalink raw reply
* [PATCH] ipvs: fix dst_lock locking on dest update
From: Julian Anastasov @ 2011-02-22 8:40 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, lvs-devel, Simon Horman
Fix dst_lock usage in __ip_vs_update_dest. We need
_bh locking because destination is updated in user context.
Can cause lockups on frequent destination updates.
Problem reported by Simon Kirby. Bug was introduced
in 2.6.37 from the "ipvs: changes for local real server"
change.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
Dave, please apply to net-2.6.
Patch is for 2.6.37+ and applies to 2.6.38-rc6. There is
little fuzz when applying to net-next, let me know if
I should provide patch for other trees.
--- linux-2.6.37/net/netfilter/ipvs/ip_vs_ctl.c 2011-01-06 00:01:23.600069161 +0200
+++ linux/net/netfilter/ipvs/ip_vs_ctl.c 2011-02-19 23:14:44.463250743 +0200
@@ -810,9 +810,9 @@ __ip_vs_update_dest(struct ip_vs_service
dest->u_threshold = udest->u_threshold;
dest->l_threshold = udest->l_threshold;
- spin_lock(&dest->dst_lock);
+ spin_lock_bh(&dest->dst_lock);
ip_vs_dst_reset(dest);
- spin_unlock(&dest->dst_lock);
+ spin_unlock_bh(&dest->dst_lock);
if (add)
ip_vs_new_estimator(&dest->stats);
^ permalink raw reply
* RE: [PATCH 3/5] r8169: fix the wrong parameter of point address
From: hayeswang @ 2011-02-22 8:46 UTC (permalink / raw)
To: 'Francois Romieu'; +Cc: netdev, linux-kernel
In-Reply-To: <20110222082153.GA12463@electric-eye.fr.zoreil.com>
> -----Original Message-----
> From: Francois Romieu [mailto:romieu@fr.zoreil.com]
> Sent: Tuesday, February 22, 2011 4:22 PM
> To: Hayeswang
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 3/5] r8169: fix the wrong parameter of
> point address
>
> Francois Romieu <romieu@fr.zoreil.com> :
> > Hayes Wang <hayeswang@realtek.com> :
> > > Correct the parameter of rtl8168_oob_notify. It results
> in the wrong
> > > point address and influences RTL8168DP.
> >
> > Please send this one separately as a patch against current
> kernel tree
> > as it is clearly a bugfix. The remaining patches are probably more
> > -next material.
>
> Correct me if I am wrong:
> - #3 and #1 are bugfixes
> - can you specify if #4 and #5 are either bugfixes,
> optimizations or cleanups ?
> - #2 adds support for a new chipset
#1, #3, #4 are bugfixes.
#2 adds support for a new chipset
#5 is cleanup.
I would separate them and send the patches again.
Best Regards,
Hayes
^ permalink raw reply
* Re: [PATCH] ipvs: fix dst_lock locking on dest update
From: Hans Schillstrom @ 2011-02-22 9:11 UTC (permalink / raw)
To: Julian Anastasov; +Cc: David S. Miller, netdev, lvs-devel, Simon Horman
>---- Original Message ----
>From: Julian Anastasov <ja@ssi.bg>
>To: "David S. Miller" <davem@davemloft.net>
>Cc: netdev@vger.kernel.org, lvs-devel@vger.kernel.org, "Simon Horman" <horms@verge.net.au>
>Sent: Tue, Feb 22, 2011, 9:36 AM
>Subject: [PATCH] ipvs: fix dst_lock locking on dest update
>
>Fix dst_lock usage in __ip_vs_update_dest. We need
>_bh locking because destination is updated in user context.
>Can cause lockups on frequent destination updates.
>Problem reported by Simon Kirby. Bug was introduced
>in 2.6.37 from the "ipvs: changes for local real server"
>change.
>
>Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Hans Schillstrom <hans@schillstrom.com>
>---
>
> Dave, please apply to net-2.6.
>Patch is for 2.6.37+ and applies to 2.6.38-rc6. There is
>little fuzz when applying to net-next, let me know if
>I should provide patch for other trees.
The patch seems to be OK in 2.6.38 expcept for line number.
All my thest runs without any problems.
>
>--- linux-2.6.37/net/netfilter/ipvs/ip_vs_ctl.c 2011-01-06 00:01:23.600069161 +0200
>+++ linux/net/netfilter/ipvs/ip_vs_ctl.c 2011-02-19 23:14:44.463250743 +0200
>@@ -810,9 +810,9 @@ __ip_vs_update_dest(struct ip_vs_service
> dest->u_threshold = udest->u_threshold;
> dest->l_threshold = udest->l_threshold;
>
>- spin_lock(&dest->dst_lock);
>+ spin_lock_bh(&dest->dst_lock);
> ip_vs_dst_reset(dest);
>- spin_unlock(&dest->dst_lock);
>+ spin_unlock_bh(&dest->dst_lock);
>
> if (add)
> ip_vs_new_estimator(&dest->stats);
>--
Hans Schillstrom <hans@schillstrom.com>
^ permalink raw reply
* [PATCH 1/2] net/r8169: adjust rtl8169_set_speed_xmii function
From: Hayes Wang @ 2011-02-22 9:26 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
Adjust code of rtl8169_set_speed_xmii function and remove part
codes which have done in rtl_pll_power_up function.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 16 ++--------------
1 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 469ab0b..de94489 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1124,6 +1124,8 @@ static int rtl8169_set_speed_xmii(struct net_device *dev,
struct rtl8169_private *tp = netdev_priv(dev);
int giga_ctrl, bmcr;
+ rtl_writephy(tp, 0x1f, 0x0000);
+
if (autoneg == AUTONEG_ENABLE) {
int auto_nego;
@@ -1152,18 +1154,6 @@ static int rtl8169_set_speed_xmii(struct net_device *dev,
bmcr = BMCR_ANENABLE | BMCR_ANRESTART;
- if ((tp->mac_version == RTL_GIGA_MAC_VER_11) ||
- (tp->mac_version == RTL_GIGA_MAC_VER_12) ||
- (tp->mac_version >= RTL_GIGA_MAC_VER_17)) {
- /*
- * Wake up the PHY.
- * Vendor specific (0x1f) and reserved (0x0e) MII
- * registers.
- */
- rtl_writephy(tp, 0x1f, 0x0000);
- rtl_writephy(tp, 0x0e, 0x0000);
- }
-
rtl_writephy(tp, MII_ADVERTISE, auto_nego);
rtl_writephy(tp, MII_CTRL1000, giga_ctrl);
} else {
@@ -1178,8 +1168,6 @@ static int rtl8169_set_speed_xmii(struct net_device *dev,
if (duplex == DUPLEX_FULL)
bmcr |= BMCR_FULLDPLX;
-
- rtl_writephy(tp, 0x1f, 0x0000);
}
tp->phy_1000_ctrl_reg = giga_ctrl;
--
1.7.3.2
^ permalink raw reply related
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