* [net-next v2 71/71] drivers/net: Kconfig and Makefile cleanup
From: Jeff Kirsher @ 2011-07-31 3:27 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann
In-Reply-To: <1312082850-24914-1-git-send-email-jeffrey.t.kirsher@intel.com>
After the move of the Ethernet drivers into drivers/net/ethernet/
there was some leftover cleanup to do in the Kconfig and Makefile.
Removed the 10/100, 1000, and 10GbE Kconfig menus.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/Kconfig | 113 ------------------------------------------
drivers/net/Makefile | 4 --
drivers/net/ethernet/Kconfig | 3 +
3 files changed, 3 insertions(+), 117 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6fce41b..31d8792 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -192,119 +192,6 @@ source "drivers/net/phy/Kconfig"
source "drivers/net/ethernet/Kconfig"
-menuconfig NET_ETHERNET
- bool "Ethernet (10 or 100Mbit)"
- depends on !UML
- ---help---
- Ethernet (also called IEEE 802.3 or ISO 8802-2) is the most common
- type of Local Area Network (LAN) in universities and companies.
-
- Common varieties of Ethernet are: 10BASE-2 or Thinnet (10 Mbps over
- coaxial cable, linking computers in a chain), 10BASE-T or twisted
- pair (10 Mbps over twisted pair cable, linking computers to central
- hubs), 10BASE-F (10 Mbps over optical fiber links, using hubs),
- 100BASE-TX (100 Mbps over two twisted pair cables, using hubs),
- 100BASE-T4 (100 Mbps over 4 standard voice-grade twisted pair
- cables, using hubs), 100BASE-FX (100 Mbps over optical fiber links)
- [the 100BASE varieties are also known as Fast Ethernet], and Gigabit
- Ethernet (1 Gbps over optical fiber or short copper links).
-
- If your Linux machine will be connected to an Ethernet and you have
- an Ethernet network interface card (NIC) installed in your computer,
- say Y here and read the Ethernet-HOWTO, available from
- <http://www.tldp.org/docs.html#howto>. You will then also have
- to say Y to the driver for your particular NIC.
-
- Note that the answer to this question won't directly affect the
- kernel: saying N will just cause the configurator to skip all
- the questions about Ethernet network cards. If unsure, say N.
-
-if NET_ETHERNET
-
-config NET_PCI
- bool "EISA, VLB, PCI and on board controllers"
- depends on ISA || EISA || PCI
- help
- This is another class of network cards which attach directly to the
- bus. If you have one of those, say Y and read the Ethernet-HOWTO,
- available from <http://www.tldp.org/docs.html#howto>.
-
- Note that the answer to this question doesn't directly affect the
- kernel: saying N will just cause the configurator to skip all
- the questions about this class of network cards. If you say Y, you
- will be asked for your specific card in the following questions. If
- you are unsure, say Y.
-
-config NET_POCKET
- bool "Pocket and portable adapters"
- depends on PARPORT
- ---help---
- Cute little network (Ethernet) devices which attach to the parallel
- port ("pocket adapters"), commonly used with laptops. If you have
- one of those, say Y and read the Ethernet-HOWTO, available from
- <http://www.tldp.org/docs.html#howto>.
-
- If you want to plug a network (or some other) card into the PCMCIA
- (or PC-card) slot of your laptop instead (PCMCIA is the standard for
- credit card size extension cards used by all modern laptops), you
- need the pcmcia-cs package (location contained in the file
- <file:Documentation/Changes>) and you can say N here.
-
- Laptop users should read the Linux Laptop home page at
- <http://www.linux-on-laptops.com/> or
- Tuxmobil - Linux on Mobile Computers at <http://www.tuxmobil.org/>.
-
- Note that the answer to this question doesn't directly affect the
- kernel: saying N will just cause the configurator to skip all
- the questions about this class of network devices. If you say Y, you
- will be asked for your specific device in the following questions.
-
-endif # NET_ETHERNET
-
-#
-# Gigabit Ethernet
-#
-
-menuconfig NETDEV_1000
- bool "Ethernet (1000 Mbit)"
- depends on !UML
- default y
- ---help---
- Ethernet (also called IEEE 802.3 or ISO 8802-2) is the most common
- type of Local Area Network (LAN) in universities and companies.
-
- Say Y here to get to see options for Gigabit Ethernet drivers.
- This option alone does not add any kernel code.
- Note that drivers supporting both 100 and 1000 MBit may be listed
- under "Ethernet (10 or 100MBit)" instead.
-
- If you say N, all options in this submenu will be skipped and disabled.
-
-if NETDEV_1000
-
-endif # NETDEV_1000
-
-#
-# 10 Gigabit Ethernet
-#
-
-menuconfig NETDEV_10000
- bool "Ethernet (10000 Mbit)"
- depends on !UML
- default y
- ---help---
- Say Y here to get to see options for 10 Gigabit Ethernet drivers.
- This option alone does not add any kernel code.
-
- If you say N, all options in this submenu will be skipped and disabled.
-
-if NETDEV_10000
-
-config MDIO
- tristate
-
-endif # NETDEV_10000
-
source "drivers/net/tokenring/Kconfig"
source "drivers/net/wireless/Kconfig"
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index fcc62e6..9cb47bb 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -13,9 +13,7 @@ obj-$(CONFIG_VMXNET3) += vmxnet3/
# link order important here
#
obj-$(CONFIG_PLIP) += plip.o
-
obj-$(CONFIG_ROADRUNNER) += rrunner.o
-
obj-$(CONFIG_SKFP) += skfp/
obj-$(CONFIG_RIONET) += rionet.o
@@ -25,7 +23,6 @@ obj-$(CONFIG_RIONET) += rionet.o
obj-$(CONFIG_NET) += Space.o loopback.o
obj-$(CONFIG_NET_SB1000) += sb1000.o
-
obj-$(CONFIG_PPP) += ppp_generic.o
obj-$(CONFIG_PPP_ASYNC) += ppp_async.o
obj-$(CONFIG_PPP_SYNC_TTY) += ppp_synctty.o
@@ -35,7 +32,6 @@ obj-$(CONFIG_PPP_MPPE) += ppp_mppe.o
obj-$(CONFIG_PPPOE) += pppox.o pppoe.o
obj-$(CONFIG_PPPOL2TP) += pppox.o
obj-$(CONFIG_PPTP) += pppox.o pptp.o
-
obj-$(CONFIG_SLIP) += slip.o
obj-$(CONFIG_SLHC) += slhc.o
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index cff6ef5..9ed3dc7 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -11,6 +11,9 @@ menuconfig ETHERNET
if ETHERNET
+config MDIO
+ tristate
+
source "drivers/net/ethernet/3com/Kconfig"
source "drivers/net/ethernet/adaptec/Kconfig"
source "drivers/net/ethernet/aeroflex/Kconfig"
--
1.7.6
^ permalink raw reply related
* [net-next v2 70/71] tile: Move the Tilera driver
From: Jeff Kirsher @ 2011-07-31 3:27 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann, Chris Metcalf
In-Reply-To: <1312082850-24914-1-git-send-email-jeffrey.t.kirsher@intel.com>
Move the Tilera driver into drivers/net/ethernet/tile and
make the necessary Kconfig and Makefile changes.
CC: Chris Metcalf <cmetcalf@tilera.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
MAINTAINERS | 2 +-
drivers/net/Kconfig | 12 ------------
drivers/net/Makefile | 2 --
drivers/net/ethernet/Kconfig | 1 +
drivers/net/ethernet/Makefile | 1 +
drivers/net/ethernet/tile/Kconfig | 28 ++++++++++++++++++++++++++++
drivers/net/{ => ethernet}/tile/Makefile | 0
drivers/net/{ => ethernet}/tile/tilepro.c | 0
8 files changed, 31 insertions(+), 15 deletions(-)
create mode 100644 drivers/net/ethernet/tile/Kconfig
rename drivers/net/{ => ethernet}/tile/Makefile (100%)
rename drivers/net/{ => ethernet}/tile/tilepro.c (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index d3a0a99..b7cf059 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6233,7 +6233,7 @@ W: http://www.tilera.com/scm/
S: Supported
F: arch/tile/
F: drivers/tty/hvc/hvc_tile.c
-F: drivers/net/tile/
+F: drivers/net/ethernet/tile/
F: drivers/edac/tile_edac.c
TLAN NETWORK DRIVER
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index a4d2704..6fce41b 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -325,18 +325,6 @@ source "drivers/s390/net/Kconfig"
source "drivers/net/caif/Kconfig"
-config TILE_NET
- tristate "Tilera GBE/XGBE network driver support"
- depends on TILE
- default y
- select CRC32
- help
- This is a standard Linux network device driver for the
- on-chip Tilera Gigabit Ethernet and XAUI interfaces.
-
- To compile this driver as a module, choose M here: the module
- will be called tile_net.
-
config XEN_NETDEV_FRONTEND
tristate "Xen network device frontend driver"
depends on XEN
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 620abd7..fcc62e6 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -79,5 +79,3 @@ obj-$(CONFIG_VIRTIO_NET) += virtio_net.o
obj-$(CONFIG_WIMAX) += wimax/
obj-$(CONFIG_CAIF) += caif/
-
-obj-$(CONFIG_TILE_NET) += tile/
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index f011665..cff6ef5 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -156,6 +156,7 @@ source "drivers/net/ethernet/stmicro/Kconfig"
source "drivers/net/ethernet/sun/Kconfig"
source "drivers/net/ethernet/tehuti/Kconfig"
source "drivers/net/ethernet/ti/Kconfig"
+source "drivers/net/ethernet/tile/Kconfig"
source "drivers/net/ethernet/toshiba/Kconfig"
source "drivers/net/ethernet/tundra/Kconfig"
source "drivers/net/ethernet/via/Kconfig"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 7f3b73c..fdf11aa 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_NET_VENDOR_STMICRO) += stmicro/
obj-$(CONFIG_NET_VENDOR_SUN) += sun/
obj-$(CONFIG_NET_VENDOR_TEHUTI) += tehuti/
obj-$(CONFIG_NET_VENDOR_TI) += ti/
+obj-$(CONFIG_NET_VENDOR_TILERA) += tile/
obj-$(CONFIG_NET_VENDOR_TOSHIBA) += toshiba/
obj-$(CONFIG_NET_VENDOR_TUNDRA) += tundra/
obj-$(CONFIG_NET_VENDOR_VIA) += via/
diff --git a/drivers/net/ethernet/tile/Kconfig b/drivers/net/ethernet/tile/Kconfig
new file mode 100644
index 0000000..e344353
--- /dev/null
+++ b/drivers/net/ethernet/tile/Kconfig
@@ -0,0 +1,28 @@
+#
+# Tilera network device configuration
+#
+
+config NET_VENDOR_TILERA
+ bool "Tilera devices"
+ depends on TILE
+ ---help---
+ If you have a network (Ethernet) card belonging to this class, say Y
+ and read the Ethernet-HOWTO, available from
+ <http://www.tldp.org/docs.html#howto>.
+
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all
+ the questions about Tilera cards. If you say Y, you will be asked for
+ your specific card in the following questions.
+
+config TILE_NET
+ tristate "Tilera GBE/XGBE network driver support"
+ depends on NET_VENDOR_TILERA && TILE
+ default y
+ select CRC32
+ ---help---
+ This is a standard Linux network device driver for the
+ on-chip Tilera Gigabit Ethernet and XAUI interfaces.
+
+ To compile this driver as a module, choose M here: the module
+ will be called tile_net.
diff --git a/drivers/net/tile/Makefile b/drivers/net/ethernet/tile/Makefile
similarity index 100%
rename from drivers/net/tile/Makefile
rename to drivers/net/ethernet/tile/Makefile
diff --git a/drivers/net/tile/tilepro.c b/drivers/net/ethernet/tile/tilepro.c
similarity index 100%
rename from drivers/net/tile/tilepro.c
rename to drivers/net/ethernet/tile/tilepro.c
--
1.7.6
^ permalink raw reply related
* Re: [PATCH RFC net-next] virtio_net: refill buffer right after being used
From: Shirley Ma @ 2011-07-31 5:16 UTC (permalink / raw)
To: Mike Waychison; +Cc: virtualization, netdev, kvm, mst
In-Reply-To: <CAGTjWtCsgcf664HJ_prmcRyUzLcSSKhjfbaM0KnsxhDJo6k7Fg@mail.gmail.com>
On Fri, 2011-07-29 at 16:58 -0700, Mike Waychison wrote:
> On Fri, Jul 29, 2011 at 3:55 PM, Shirley Ma <mashirle@us.ibm.com>
> wrote:
> > Resubmit it with a typo fix.
> >
> > Signed-off-by: Shirley Ma <xma@us.ibm.com>
> > ---
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 0c7321c..c8201d4 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -429,6 +429,22 @@ static int add_recvbuf_mergeable(struct
> virtnet_info *vi, gfp_t gfp)
> > return err;
> > }
> >
> > +static int fill_one(struct virtnet_info *vi, gfp_t gfp)
> > +{
> > + int err;
> > +
> > + if (vi->mergeable_rx_bufs)
> > + err = add_recvbuf_mergeable(vi, gfp);
> > + else if (vi->big_packets)
> > + err = add_recvbuf_big(vi, gfp);
> > + else
> > + err = add_recvbuf_small(vi, gfp);
> > +
> > + if (err >= 0)
> > + ++vi->num;
> > + return err;
> > +}
> > +
> > /* Returns false if we couldn't fill entirely (OOM). */
> > static bool try_fill_recv(struct virtnet_info *vi, gfp_t gfp)
> > {
> > @@ -436,17 +452,10 @@ static bool try_fill_recv(struct virtnet_info
> *vi, gfp_t gfp)
> > bool oom;
> >
> > do {
> > - if (vi->mergeable_rx_bufs)
> > - err = add_recvbuf_mergeable(vi, gfp);
> > - else if (vi->big_packets)
> > - err = add_recvbuf_big(vi, gfp);
> > - else
> > - err = add_recvbuf_small(vi, gfp);
> > -
> > + err = fill_one(vi, gfp);
> > oom = err == -ENOMEM;
> > if (err < 0)
> > break;
> > - ++vi->num;
> > } while (err > 0);
> > if (unlikely(vi->num > vi->max))
> > vi->max = vi->num;
> > @@ -506,13 +515,13 @@ again:
> > receive_buf(vi->dev, buf, len);
> > --vi->num;
> > received++;
> > - }
> > -
> > - if (vi->num < vi->max / 2) {
> > - if (!try_fill_recv(vi, GFP_ATOMIC))
> > + if (fill_one(vi, GFP_ATOMIC) < 0)
> > schedule_delayed_work(&vi->refill, 0);
> > }
> >
> > + /* notify buffers are refilled */
> > + virtqueue_kick(vi->rvq);
> > +
>
> How does this reduce latency? We are doing the same amount of work
> in both cases, and in both cases the newly available buffers are not
> visible to the device until the virtqueue_kick..
It averages the latency between each receive by filling only one set of
buffers vs. either none buffers or 1/2 ring size buffers fill between
receives.
>
> > /* Out of packets? */
> > if (received < budget) {
> > napi_complete(napi);
> >
> >
> > --
^ permalink raw reply
* Re: [PATCH] sunrpc: use better NUMA affinities
From: Eric Dumazet @ 2011-07-31 6:58 UTC (permalink / raw)
To: NeilBrown
Cc: J. Bruce Fields, Greg Banks, Christoph Hellwig,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, David Miller,
linux-kernel, netdev
In-Reply-To: <1312006990.2873.75.camel@edumazet-laptop>
Le samedi 30 juillet 2011 à 08:23 +0200, Eric Dumazet a écrit :
> Le samedi 30 juillet 2011 à 16:06 +1000, NeilBrown a écrit :
> > umount /proc/fs/nfsd
> >
> >
>
> Thans a lot, this was the thing I missed !
>
>
Hmm, after this, I left things as the were (nfsd module loaded, but a 0
use count )
I got a BUG while updatedb was running,
(I tried this on a debian machine/kernel)
Same bug on :
cat /proc/self/mounts
I'll take a look at this issue later, after my vacations, unless someone
wants to take a look before me ;)
[1020029.301174] BUG: unable to handle kernel paging request at ffffffffa03da0d0
[1020029.301318] IP: [<ffffffff811105bd>] show_type+0x17/0x5a
[1020029.301436] PGD 1605067 PUD 1609063 PMD 127353067 PTE 0
[1020029.301574] Oops: 0000 [#1] SMP
[1020029.301637] last sysfs file: /sys/module/nfsd/initstate
[1020029.301722] CPU 6
[1020029.301765] Modules linked in: nfsd fuse btrfs zlib_deflate crc32c libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs reiserfs ext4 jbd2 crc16 ext2 dm_mod nls_utf8 isofs lockd fscache auth_rpcgss nfs_acl sunrpc loop i5000_edac radeon edac_core ttm drm_kms_helper snd_pcm drm snd_timer snd i2c_algo_bit soundcore i2c_core snd_page_alloc i5k_amb power_supply ipmi_si evdev psmouse rng_core ipmi_msghandler hpilo hpwdt shpchp processor button pcspkr serio_raw pci_hotplug container ext3 jbd mbcache hpsa usbhid hid uhci_hcd cciss scsi_mod ehci_hcd usbcore bnx2 thermal thermal_sys [last unloaded: nfsd]
[1020029.303561]
[1020029.303588] Pid: 23460, comm: updatedb.mlocat Tainted: G R 2.6.39-2-amd64 #1 HP ProLiant BL460c G1
[1020029.303751] RIP: 0010:[<ffffffff811105bd>] [<ffffffff811105bd>] show_type+0x17/0x5a
[1020029.303866] RSP: 0018:ffff880011da7e48 EFLAGS: 00010296
[1020029.303953] RAX: ffffffffa03da0d0 RBX: ffff8801288a4a80 RCX: 0000000000007774
[1020029.304061] RDX: ffffffff814c9935 RSI: ffff880129ea3800 RDI: ffff8801288a4a80
[1020029.304169] RBP: ffff880129ea3800 R08: ffff880011da7e68 R09: ffffffffffffffff
[1020029.304263] R10: ffff880011d883b2 R11: 0000000000000007 R12: ffff88012794a2c0
[1020029.304263] R13: ffff8801288a4a80 R14: ffff88012794a338 R15: 0000000000000000
[1020029.304263] FS: 00007f9cf0dec700(0000) GS:ffff88012fd80000(0000) knlGS:0000000000000000
[1020029.304263] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[1020029.304263] CR2: ffffffffa03da0d0 CR3: 0000000058f90000 CR4: 00000000000006e0
[1020029.304263] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[1020029.304263] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[1020029.304263] Process updatedb.mlocat (pid: 23460, threadinfo ffff880011da6000, task ffff88002741a440)
[1020029.304263] Stack:
[1020029.304263] ffff8801288a4a80 ffff8801288a4a80 ffff88012794a338 ffffffff81110abf
[1020029.304263] ffff88012794a2c0 ffff88010d992440 0000000000000400 00007f9cf0df3000
[1020029.304263] ffff880127960cc0 ffff8801288a4a80 ffff88012794a338 ffffffff8111427a
[1020029.304263] Call Trace:
[1020029.304263] [<ffffffff81110abf>] ? show_vfsmnt+0x9b/0x134
[1020029.304263] [<ffffffff8111427a>] ? seq_read+0x276/0x350
[1020029.304263] [<ffffffff810fc207>] ? vfs_read+0xa1/0xfb
[1020029.304263] [<ffffffff810d8052>] ? sys_mmap_pgoff+0x127/0x15a
[1020029.304263] [<ffffffff810fc317>] ? sys_read+0x45/0x6e
[1020029.304263] [<ffffffff81338e52>] ? system_call_fastpath+0x16/0x1b
[1020029.304263] Code: 01 00 65 48 03 14 25 20 dc 00 00 66 ff 02 c3 f0 ff 47 38 c3 55 48 89 f5 48 c7 c2 35 99 4c 81 53 48 89 fb 48 83 ec 08 48 8b 46 28
[1020029.304263] 8b 30 e8 c7 36 00 00 48 8b 85 b8 02 00 00 48 85 c0 74 2b 80
[1020029.304263] RIP [<ffffffff811105bd>] show_type+0x17/0x5a
[1020029.304263] RSP <ffff880011da7e48>
[1020029.304263] CR2: ffffffffa03da0d0
[1020029.311417] ---[ end trace ebf19aff1e083659 ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next v2 09/71] smsc: Move the SMC (SMSC) drivers
From: Jeff Kirsher @ 2011-07-31 7:17 UTC (permalink / raw)
To: davem
Cc: Jeff Kirsher, netdev, gospo, sassmann, Nicolas Pitre,
Donald Becker, Erik Stahlman, Dustin McIntire, Steve Glendinning,
David Hinds
In-Reply-To: <1312082850-24914-10-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Jul 30, 2011 at 20:26, Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> Moves the SMC (SMSC) drivers into drivers/net/ethernet/smsc/ and the
> necessary Kconfig and Makefile changes. Also did some cleanup
> of NET_VENDOR_SMC Kconfig tag for the 8390 based drivers.
>
> CC: Nicolas Pitre <nico@fluxnic.net>
> CC: Donald Becker <becker@scyld.com>
> CC: Erik Stahlman <erik@vt.edu>
> CC: Dustin McIntire <dustin@sensoria.com>
> CC: Steve Glendinning <steve.glendinning@smsc.com>
> CC: David Hinds <dahinds@users.sourceforge.net>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> MAINTAINERS | 6 +-
> drivers/net/Kconfig | 105 ----------------
> drivers/net/Makefile | 7 -
> drivers/net/ethernet/8390/Kconfig | 21 +---
> drivers/net/ethernet/Kconfig | 1 +
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/ethernet/smsc/Kconfig | 128 ++++++++++++++++++++
> drivers/net/ethernet/smsc/Makefile | 11 ++
> drivers/net/{ => ethernet/smsc}/epic100.c | 0
> drivers/net/{ => ethernet/smsc}/smc911x.c | 0
> drivers/net/{ => ethernet/smsc}/smc911x.h | 0
> drivers/net/{ => ethernet/smsc}/smc9194.c | 0
> drivers/net/{ => ethernet/smsc}/smc9194.h | 0
> .../net/{pcmcia => ethernet/smsc}/smc91c92_cs.c | 0
> drivers/net/{ => ethernet/smsc}/smc91x.c | 0
> drivers/net/{ => ethernet/smsc}/smc91x.h | 0
> drivers/net/{ => ethernet/smsc}/smsc911x.c | 0
> drivers/net/{ => ethernet/smsc}/smsc911x.h | 0
> drivers/net/{ => ethernet/smsc}/smsc9420.c | 0
> drivers/net/{ => ethernet/smsc}/smsc9420.h | 0
> drivers/net/pcmcia/Kconfig | 11 --
> drivers/net/pcmcia/Makefile | 1 -
> 22 files changed, 148 insertions(+), 144 deletions(-)
> create mode 100644 drivers/net/ethernet/smsc/Kconfig
> create mode 100644 drivers/net/ethernet/smsc/Makefile
> rename drivers/net/{ => ethernet/smsc}/epic100.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smc911x.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smc911x.h (100%)
> rename drivers/net/{ => ethernet/smsc}/smc9194.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smc9194.h (100%)
> rename drivers/net/{pcmcia => ethernet/smsc}/smc91c92_cs.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smc91x.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smc91x.h (100%)
> rename drivers/net/{ => ethernet/smsc}/smsc911x.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smsc911x.h (100%)
> rename drivers/net/{ => ethernet/smsc}/smsc9420.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smsc9420.h (100%)
>
...[snip] ...
> diff --git a/drivers/net/ethernet/smsc/Kconfig b/drivers/net/ethernet/smsc/Kconfig
> new file mode 100644
> index 0000000..dbb3069
> --- /dev/null
> +++ b/drivers/net/ethernet/smsc/Kconfig
> @@ -0,0 +1,128 @@
> +#
> +# Western Digital/SMC network device configuration
> +#
> +
> +config NET_VENDOR_SMSC
> + bool "SMC (SMSC)/Western Digital devices"
> + depends on ARM || ISA || MAC || ARM || MIPS || M32R || SUPERH || \
> + BLACKFIN || MN10300 || COLDFIRE || PCI || PCMCIA
> + ---help---
> + If you have a network (Ethernet) card belonging to this class, say Y
> + and read the Ethernet-HOWTO, available from
> + <http://www.tldp.org/docs.html#howto>.
> +
> + Note that the answer to this question doesn't directly affect the
> + kernel: saying N will just cause the configurator to skip all
> + the questions about SMC/Western Digital cards. If you say Y, you will
> + be asked for your specific card in the following questions.
> +
> +config SMC9194
> + tristate "SMC 9194 support"
> + depends on NET_VENDOR_SMSC && (ISA || MAC && BROKEN)
> + select CRC32
> + ---help---
> + This is support for the SMC9xxx based Ethernet cards. Choose this
> + option if you have a DELL laptop with the docking station, or
> + another SMC9192/9194 based chipset. Say Y if you want it compiled
> + into the kernel, and read the file
> + <file:Documentation/networking/smc9.txt> and the Ethernet-HOWTO,
> + available from <http://www.tldp.org/docs.html#howto>.
> +
> + To compile this driver as a module, choose M here. The module
> + will be called smc9194.
> +
> +config SMC91X
> + tristate "SMC 91C9x/91C1xxx support"
> + select CRC32
> + select MII
> + depends on NET_VENDOR_SMSC && (ARM || M32R || SUPERH || \
> + MIPS || BLACKFIN || MN10300 || COLDFIRE)
> + ---help---
> + This is a driver for SMC's 91x series of Ethernet chipsets,
> + including the SMC91C94 and the SMC91C111. Say Y if you want it
> + compiled into the kernel, and read the file
> + <file:Documentation/networking/smc9.txt> and the Ethernet-HOWTO,
> + available from <http://www.tldp.org/docs.html#howto>.
> +
> + This driver is also available as a module ( = code which can be
> + inserted in and removed from the running kernel whenever you want).
> + The module will be called smc91x. If you want to compile it as a
> + module, say M here and read <file:Documentation/kbuild/modules.txt>.
> +
> +config PCMCIA_SMC91C92
> + tristate "SMC 91Cxx PCMCIA support"
> + depends NET_VENDOR_SMSC && PCMCIA
Found a typo, should be "DEPENDS ON ..." , I will fix up the patch on my tree.
--
Cheers,
Jeff
^ permalink raw reply
* Re: [net-next v2 03/71] amd: Move AMD (Lance) chipset drivers
From: Geert Uytterhoeven @ 2011-07-31 8:14 UTC (permalink / raw)
To: Jeff Kirsher
Cc: davem, netdev, gospo, sassmann, Peter Maydell, Roman Hodek,
Maciej W. Rozycki, Donald Becker, Sam Creasey, Miguel de Icaza,
Thomas Bogendoerfer, Don Fry, Russell King, David Davies, M.Hipp,
Pete Popov, David Hinds, Roger C. Pao
In-Reply-To: <1312082850-24914-4-git-send-email-jeffrey.t.kirsher@intel.com>
On Sun, Jul 31, 2011 at 05:26, Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> --- /dev/null
> +++ b/drivers/net/ethernet/amd/Kconfig
> @@ -0,0 +1,188 @@
> +#
> +# AMD network device configuration
> +#
> +
> +config NET_VENDOR_AMD
> + bool "AMD devices"
> + depends on DIO || MACH_DECSTATION || MVME147 || ATARI || SUN3 || \
> + SUN3X || SBUS || PCI || ZORRO || (ISA && ISA_DMA_API) || \
> + (ARM && ARCH_EBSA110) || ISA || EISA || MCA || PCMCIA
Do you really need this big dependency? It will be true in almost all
cases anyway,
and the individual driver options are protected by other dependencies.
Just enabling this option doesn't make the kernel bigger.
> + ---help---
> + If you have a network (Ethernet) chipset belonging to this class,
> + say Y.
> +
> + Note that the answer to this question does not directly affect
> + the kernel: saying N will just case the configurator to skip all
> + the questions regarding AMD chipsets. If you say Y, you will be asked
> + for your specific chipset/driver in the following questions.
> +
> +config A2065
> + tristate "A2065 support"
> + depends on NET_VENDOR_AMD && ZORRO
What about putting all driver sections inside "if NET_VENDOR_AMD" /
"endif", so the
individual driver configs don't need to depend on NET_VENDOR_AMD anymore?
The rest looks fine to me.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [net-next v2 03/71] amd: Move AMD (Lance) chipset drivers
From: Jeff Kirsher @ 2011-07-31 8:30 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: davem@davemloft.net, netdev@vger.kernel.org, gospo@redhat.com,
sassmann@redhat.com, Peter Maydell, Roman Hodek,
Maciej W. Rozycki, Donald Becker, Sam Creasey, Miguel de Icaza,
Thomas Bogendoerfer, Don Fry, Russell King, David Davies, M.Hipp,
Pete Popov, David Hinds, Roger C. Pao
In-Reply-To: <CAMuHMdXYoKkZrczdB6qPC1pfAGoTqgOiK2joY-38dewrVm5cRQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2693 bytes --]
On Sun, 2011-07-31 at 01:14 -0700, Geert Uytterhoeven wrote:
> On Sun, Jul 31, 2011 at 05:26, Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> > --- /dev/null
> > +++ b/drivers/net/ethernet/amd/Kconfig
> > @@ -0,0 +1,188 @@
> > +#
> > +# AMD network device configuration
> > +#
> > +
> > +config NET_VENDOR_AMD
> > + bool "AMD devices"
> > + depends on DIO || MACH_DECSTATION || MVME147 || ATARI || SUN3 || \
> > + SUN3X || SBUS || PCI || ZORRO || (ISA && ISA_DMA_API) || \
> > + (ARM && ARCH_EBSA110) || ISA || EISA || MCA || PCMCIA
>
> Do you really need this big dependency? It will be true in almost all
> cases anyway,
> and the individual driver options are protected by other dependencies.
> Just enabling this option doesn't make the kernel bigger.
My thought behind this was from the standpoint, if I have system/arch
which is not listed here and I am using menuconfig, I would not want to
see an option listed that does not have any value or drivers which I
could select.
>
> > + ---help---
> > + If you have a network (Ethernet) chipset belonging to this class,
> > + say Y.
> > +
> > + Note that the answer to this question does not directly affect
> > + the kernel: saying N will just case the configurator to skip all
> > + the questions regarding AMD chipsets. If you say Y, you will be asked
> > + for your specific chipset/driver in the following questions.
> > +
> > +config A2065
> > + tristate "A2065 support"
> > + depends on NET_VENDOR_AMD && ZORRO
>
> What about putting all driver sections inside "if NET_VENDOR_AMD" /
> "endif", so the
> individual driver configs don't need to depend on NET_VENDOR_AMD anymore?
Your right, I could have done that instead. I saw examples of both in
the current Kconfig's and I chose this one mainly because there were
several drivers already using this model, not that it was any better
than what you are suggesting.
Personally, after doing all the work, I do like your suggestion because
it would make it easier for adding drivers in the future, where they
would not have to "remember to add the NET_VENDOR_* to the driver
Kconfig dependency.
>
> The rest looks fine to me.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [net-next v2 26/71] xscale: Move the Intel XScale IXP drivers
From: Lennert Buytenhek @ 2011-07-31 8:38 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, gospo, sassmann, Krzysztof Halasa
In-Reply-To: <1312082850-24914-27-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Jul 30, 2011 at 08:26:45PM -0700, Jeff Kirsher wrote:
> Move the Intel XScale IXP drivers into drivers/net/ethernet/xscale/
> and make the necessary Kconfig and Makefile changes.
>
> CC: Krzysztof Halasa <khc@pm.waw.pl>
> CC: Lennert Buytenhek <kernel@wantstofly.org>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> [...]
>
> rename drivers/net/{ => ethernet/xscale}/ixp2000/Kconfig (76%)
This is pretty deeply nested, but OK.
Acked-by: Lennert Buytenhek <kernel@wantstofly.org>
^ permalink raw reply
* Re: [net-next v2 69/71] xircom: Move the Xircom driver
From: Dominik Brodowski @ 2011-07-31 8:52 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, gospo, sassmann, psheer
In-Reply-To: <1312082850-24914-70-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Jul 30, 2011 at 08:27:28PM -0700, Jeff Kirsher wrote:
> Move the Xircom driver into drivers/net/ethernet/xircom/ and
> make the necessary Kconfig and Makefile changes.
>
> CC: <psheer@icon.co.za>
> CC: Dominik Brodowski <linux@dominikbrodowski.net>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/Kconfig | 1 +
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/ethernet/xircom/Kconfig | 26 ++++++++++++++++++++
> drivers/net/ethernet/xircom/Makefile | 5 ++++
> .../net/{pcmcia => ethernet/xircom}/xirc2ps_cs.c | 0
> drivers/net/pcmcia/Kconfig | 9 -------
> drivers/net/pcmcia/Makefile | 1 -
> 7 files changed, 33 insertions(+), 10 deletions(-)
> create mode 100644 drivers/net/ethernet/xircom/Kconfig
> create mode 100644 drivers/net/ethernet/xircom/Makefile
> rename drivers/net/{pcmcia => ethernet/xircom}/xirc2ps_cs.c (100%)
>
> diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
> index df8940d..f011665 100644
> --- a/drivers/net/ethernet/Kconfig
> +++ b/drivers/net/ethernet/Kconfig
> @@ -160,5 +160,6 @@ source "drivers/net/ethernet/toshiba/Kconfig"
> source "drivers/net/ethernet/tundra/Kconfig"
> source "drivers/net/ethernet/via/Kconfig"
> source "drivers/net/ethernet/xilinx/Kconfig"
> +source "drivers/net/ethernet/xircom/Kconfig"
>
> endif # ETHERNET
> diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
> index 09f26b6..7f3b73c 100644
> --- a/drivers/net/ethernet/Makefile
> +++ b/drivers/net/ethernet/Makefile
> @@ -69,3 +69,4 @@ obj-$(CONFIG_NET_VENDOR_TOSHIBA) += toshiba/
> obj-$(CONFIG_NET_VENDOR_TUNDRA) += tundra/
> obj-$(CONFIG_NET_VENDOR_VIA) += via/
> obj-$(CONFIG_NET_VENDOR_XILINX) += xilinx/
> +obj-$(CONFIG_NET_VENDOR_XIRCOM) += xircom/
> diff --git a/drivers/net/ethernet/xircom/Kconfig b/drivers/net/ethernet/xircom/Kconfig
> new file mode 100644
> index 0000000..0e01524
> --- /dev/null
> +++ b/drivers/net/ethernet/xircom/Kconfig
> @@ -0,0 +1,26 @@
> +#
> +# Xircom network device configuration
> +#
> +
> +config NET_VENDOR_XIRCOM
> + bool "Xircom devices"
> + depends on PCMCIA
> + ---help---
> + If you have a network (Ethernet) card belonging to this class, say Y
> + and read the Ethernet-HOWTO, available from
> + <http://www.tldp.org/docs.html#howto>.
> +
> + Note that the answer to this question doesn't directly affect the
> + kernel: saying N will just cause the configurator to skip all
> + the questions about Xircom cards. If you say Y, you will be asked for
> + your specific card in the following questions.
> +
> +config PCMCIA_XIRC2PS
> + tristate "Xircom 16-bit PCMCIA support"
> + depends on NET_VENDOR_XIRCOM && PCMCIA
> + ---help---
> + Say Y here if you intend to attach a Xircom 16-bit PCMCIA (PC-card)
> + Ethernet or Fast Ethernet card to your computer.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called xirc2ps_cs. If unsure, say N.
> diff --git a/drivers/net/ethernet/xircom/Makefile b/drivers/net/ethernet/xircom/Makefile
> new file mode 100644
> index 0000000..3b7aebd
> --- /dev/null
> +++ b/drivers/net/ethernet/xircom/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for the Xircom network device drivers.
> +#
> +
> +obj-$(CONFIG_PCMCIA_XIRC2PS) += xirc2ps_cs.o
> diff --git a/drivers/net/pcmcia/xirc2ps_cs.c b/drivers/net/ethernet/xircom/xirc2ps_cs.c
> similarity index 100%
> rename from drivers/net/pcmcia/xirc2ps_cs.c
> rename to drivers/net/ethernet/xircom/xirc2ps_cs.c
> diff --git a/drivers/net/pcmcia/Kconfig b/drivers/net/pcmcia/Kconfig
> index 80d291e..12e7ae4 100644
> --- a/drivers/net/pcmcia/Kconfig
> +++ b/drivers/net/pcmcia/Kconfig
> @@ -21,15 +21,6 @@ menuconfig NET_PCMCIA
>
> if NET_PCMCIA && PCMCIA
>
> -config PCMCIA_XIRC2PS
> - tristate "Xircom 16-bit PCMCIA support"
> - help
> - Say Y here if you intend to attach a Xircom 16-bit PCMCIA (PC-card)
> - Ethernet or Fast Ethernet card to your computer.
> -
> - To compile this driver as a module, choose M here: the module will be
> - called xirc2ps_cs. If unsure, say N.
> -
> config ARCNET_COM20020_CS
> tristate "COM20020 ARCnet PCMCIA support"
> depends on ARCNET_COM20020
> diff --git a/drivers/net/pcmcia/Makefile b/drivers/net/pcmcia/Makefile
> index ccf5535..618e816 100644
> --- a/drivers/net/pcmcia/Makefile
> +++ b/drivers/net/pcmcia/Makefile
> @@ -3,7 +3,6 @@
> #
>
> # 16-bit client drivers
> -obj-$(CONFIG_PCMCIA_XIRC2PS) += xirc2ps_cs.o
> obj-$(CONFIG_ARCNET_COM20020_CS)+= com20020_cs.o
>
> obj-$(CONFIG_PCMCIA_IBMTR) += ibmtr_cs.o
> --
> 1.7.6
>
^ permalink raw reply
* Re: [PATCH] net/smsc911x: add device tree probe support
From: Grant Likely @ 2011-07-31 0:42 UTC (permalink / raw)
To: Shawn Guo
Cc: Nicolas Pitre, patches, netdev, devicetree-discuss,
Steve Glendinning, Shawn Guo, David S. Miller, linux-arm-kernel
In-Reply-To: <20110729171314.GC2241@S2100-06.ap.freescale.net>
On Sat, Jul 30, 2011 at 01:13:15AM +0800, Shawn Guo wrote:
> On Fri, Jul 29, 2011 at 10:26:29AM -0600, Grant Likely wrote:
> > On Sat, Jul 30, 2011 at 12:03:44AM +0800, Shawn Guo wrote:
> > > On Fri, Jul 29, 2011 at 09:47:23AM -0600, Grant Likely wrote:
> > > > On Fri, Jul 29, 2011 at 10:36:26AM +0800, Shawn Guo wrote:
> > > > > Since I do not get any suggestion here, I'm going to follow the driver
> > > > > name to use '911' as the model number. Please tell me if there is any
> > > > > better one.
> > > >
> > > > What is the manufacturer part name? lan9111 or lan91c11? The
> > > > manufacturer's documented part number is almost always preferred.
> > > >
> > > I just posted the v2 of the patch, and chose to use 'smsc,lan9115'
> > > which is the first model supported in the driver. This is the same
> > > approach I used with i.mx device bindings.
> >
> > You haven't answered the question.
> >
> For 9115 example, the part number in data sheet is "LAN9115".
Okay, good. Thanks.
g.
^ permalink raw reply
* Re: [RFC net-next v2 00/71] Organize/Move of the Ethernet drivers in drivers/net/
From: Alexey Dobriyan @ 2011-07-31 15:45 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev
> drivers/net/{ => ethernet/3com}/3c501.c
I for one appreciate that Linux has short overall directory
structure. At work we have like 5-6 directories before
actual code and it sucks very much.
> have tab-completion actually work
What do you mean?
^ permalink raw reply
* Re: [net-next v2 09/71] smsc: Move the SMC (SMSC) drivers
From: Nicolas Pitre @ 2011-07-31 16:47 UTC (permalink / raw)
To: Jeff Kirsher
Cc: davem, netdev, gospo, sassmann, Donald Becker, Erik Stahlman,
Dustin McIntire, Steve Glendinning, David Hinds
In-Reply-To: <1312082850-24914-10-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, 30 Jul 2011, Jeff Kirsher wrote:
> Moves the SMC (SMSC) drivers into drivers/net/ethernet/smsc/ and the
> necessary Kconfig and Makefile changes. Also did some cleanup
> of NET_VENDOR_SMC Kconfig tag for the 8390 based drivers.
>
> CC: Nicolas Pitre <nico@fluxnic.net>
> CC: Donald Becker <becker@scyld.com>
> CC: Erik Stahlman <erik@vt.edu>
> CC: Dustin McIntire <dustin@sensoria.com>
> CC: Steve Glendinning <steve.glendinning@smsc.com>
> CC: David Hinds <dahinds@users.sourceforge.net>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
> ---
> MAINTAINERS | 6 +-
> drivers/net/Kconfig | 105 ----------------
> drivers/net/Makefile | 7 -
> drivers/net/ethernet/8390/Kconfig | 21 +---
> drivers/net/ethernet/Kconfig | 1 +
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/ethernet/smsc/Kconfig | 128 ++++++++++++++++++++
> drivers/net/ethernet/smsc/Makefile | 11 ++
> drivers/net/{ => ethernet/smsc}/epic100.c | 0
> drivers/net/{ => ethernet/smsc}/smc911x.c | 0
> drivers/net/{ => ethernet/smsc}/smc911x.h | 0
> drivers/net/{ => ethernet/smsc}/smc9194.c | 0
> drivers/net/{ => ethernet/smsc}/smc9194.h | 0
> .../net/{pcmcia => ethernet/smsc}/smc91c92_cs.c | 0
> drivers/net/{ => ethernet/smsc}/smc91x.c | 0
> drivers/net/{ => ethernet/smsc}/smc91x.h | 0
> drivers/net/{ => ethernet/smsc}/smsc911x.c | 0
> drivers/net/{ => ethernet/smsc}/smsc911x.h | 0
> drivers/net/{ => ethernet/smsc}/smsc9420.c | 0
> drivers/net/{ => ethernet/smsc}/smsc9420.h | 0
> drivers/net/pcmcia/Kconfig | 11 --
> drivers/net/pcmcia/Makefile | 1 -
> 22 files changed, 148 insertions(+), 144 deletions(-)
> create mode 100644 drivers/net/ethernet/smsc/Kconfig
> create mode 100644 drivers/net/ethernet/smsc/Makefile
> rename drivers/net/{ => ethernet/smsc}/epic100.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smc911x.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smc911x.h (100%)
> rename drivers/net/{ => ethernet/smsc}/smc9194.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smc9194.h (100%)
> rename drivers/net/{pcmcia => ethernet/smsc}/smc91c92_cs.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smc91x.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smc91x.h (100%)
> rename drivers/net/{ => ethernet/smsc}/smsc911x.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smsc911x.h (100%)
> rename drivers/net/{ => ethernet/smsc}/smsc9420.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smsc9420.h (100%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index eb35265..31c76f4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5831,7 +5831,7 @@ F: mm/sl?b.c
> SMC91x ETHERNET DRIVER
> M: Nicolas Pitre <nico@fluxnic.net>
> S: Odd Fixes
> -F: drivers/net/smc91x.*
> +F: drivers/net/ethernet/smsc/smc91x.*
>
> SMM665 HARDWARE MONITOR DRIVER
> M: Guenter Roeck <linux@roeck-us.net>
> @@ -5866,13 +5866,13 @@ M: Steve Glendinning <steve.glendinning@smsc.com>
> L: netdev@vger.kernel.org
> S: Supported
> F: include/linux/smsc911x.h
> -F: drivers/net/smsc911x.*
> +F: drivers/net/ethernet/smsc/smsc911x.*
>
> SMSC9420 PCI ETHERNET DRIVER
> M: Steve Glendinning <steve.glendinning@smsc.com>
> L: netdev@vger.kernel.org
> S: Supported
> -F: drivers/net/smsc9420.*
> +F: drivers/net/ethernet/smsc/smsc9420.*
>
> SN-IA64 (Itanium) SUB-PLATFORM
> M: Jes Sorensen <jes@sgi.com>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 8879506..c0aa2e3 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -508,39 +508,6 @@ config BFIN_MAC_USE_HWSTAMP
> help
> To support the IEEE 1588 Precision Time Protocol (PTP), select y here
>
> -config SMC9194
> - tristate "SMC 9194 support"
> - depends on NET_VENDOR_SMC && (ISA || MAC && BROKEN)
> - select CRC32
> - ---help---
> - This is support for the SMC9xxx based Ethernet cards. Choose this
> - option if you have a DELL laptop with the docking station, or
> - another SMC9192/9194 based chipset. Say Y if you want it compiled
> - into the kernel, and read the file
> - <file:Documentation/networking/smc9.txt> and the Ethernet-HOWTO,
> - available from <http://www.tldp.org/docs.html#howto>.
> -
> - To compile this driver as a module, choose M here. The module
> - will be called smc9194.
> -
> -config SMC91X
> - tristate "SMC 91C9x/91C1xxx support"
> - select CRC32
> - select MII
> - depends on ARM || M32R || SUPERH || \
> - MIPS || BLACKFIN || MN10300 || COLDFIRE
> - help
> - This is a driver for SMC's 91x series of Ethernet chipsets,
> - including the SMC91C94 and the SMC91C111. Say Y if you want it
> - compiled into the kernel, and read the file
> - <file:Documentation/networking/smc9.txt> and the Ethernet-HOWTO,
> - available from <http://www.tldp.org/docs.html#howto>.
> -
> - This driver is also available as a module ( = code which can be
> - inserted in and removed from the running kernel whenever you want).
> - The module will be called smc91x. If you want to compile it as a
> - module, say M here and read <file:Documentation/kbuild/modules.txt>.
> -
> config PXA168_ETH
> tristate "Marvell pxa168 ethernet support"
> depends on CPU_PXA168
> @@ -655,44 +622,6 @@ config GRETH
> help
> Say Y here if you want to use the Aeroflex Gaisler GRETH Ethernet MAC.
>
> -config SMC911X
> - tristate "SMSC LAN911[5678] support"
> - select CRC32
> - select MII
> - depends on ARM || SUPERH || MN10300
> - help
> - This is a driver for SMSC's LAN911x series of Ethernet chipsets
> - including the new LAN9115, LAN9116, LAN9117, and LAN9118.
> - Say Y if you want it compiled into the kernel,
> - and read the Ethernet-HOWTO, available from
> - <http://www.tldp.org/docs.html#howto>.
> -
> - This driver is also available as a module. The module will be
> - called smc911x. If you want to compile it as a module, say M
> - here and read <file:Documentation/kbuild/modules.txt>
> -
> -config SMSC911X
> - tristate "SMSC LAN911x/LAN921x families embedded ethernet support"
> - depends on ARM || SUPERH || BLACKFIN || MIPS || MN10300
> - select CRC32
> - select MII
> - select PHYLIB
> - ---help---
> - Say Y here if you want support for SMSC LAN911x and LAN921x families
> - of ethernet controllers.
> -
> - To compile this driver as a module, choose M here and read
> - <file:Documentation/networking/net-modules.txt>. The module
> - will be called smsc911x.
> -
> -config SMSC911X_ARCH_HOOKS
> - def_bool n
> - depends on SMSC911X
> - help
> - If the arch enables this, it allows the arch to implement various
> - hooks for more comprehensive interrupt control and also to override
> - the source of the MAC address.
> -
> config NET_VENDOR_RACAL
> bool "Racal-Interlan (Micom) NI cards"
> depends on ISA
> @@ -1091,33 +1020,6 @@ config SIS900
> To compile this driver as a module, choose M here: the module
> will be called sis900. This is recommended.
>
> -config EPIC100
> - tristate "SMC EtherPower II"
> - depends on NET_PCI && PCI
> - select CRC32
> - select MII
> - help
> - This driver is for the SMC EtherPower II 9432 PCI Ethernet NIC,
> - which is based on the SMC83c17x (EPIC/100).
> - More specific information and updates are available from
> - <http://www.scyld.com/network/epic100.html>.
> -
> -config SMSC9420
> - tristate "SMSC LAN9420 PCI ethernet adapter support"
> - depends on NET_PCI && PCI
> - select CRC32
> - select PHYLIB
> - select SMSC_PHY
> - help
> - This is a driver for SMSC's LAN9420 PCI ethernet adapter.
> - Say Y if you want it compiled into the kernel,
> - and read the Ethernet-HOWTO, available from
> - <http://www.tldp.org/docs.html#howto>.
> -
> - This driver is also available as a module. The module will be
> - called smsc9420. If you want to compile it as a module, say M
> - here and read <file:Documentation/kbuild/modules.txt>
> -
> config SUNDANCE
> tristate "Sundance Alta support"
> depends on NET_PCI && PCI
> @@ -1834,13 +1736,6 @@ config MYRI10GE_DCA
> driver. DCA is a method for warming the CPU cache before data
> is used, with the intent of lessening the impact of cache misses.
>
> -config NETXEN_NIC
> - tristate "NetXen Multi port (1/10) Gigabit Ethernet NIC"
> - depends on PCI
> - select FW_LOADER
> - help
> - This enables the support for NetXen's Gigabit Ethernet card.
> -
> config NIU
> tristate "Sun Neptune 10Gbit Ethernet support"
> depends on PCI
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 8e41978..4dfa35c 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -55,8 +55,6 @@ obj-$(CONFIG_MACE) += mace.o
> obj-$(CONFIG_BMAC) += bmac.o
>
> obj-$(CONFIG_TLAN) += tlan.o
> -obj-$(CONFIG_EPIC100) += epic100.o
> -obj-$(CONFIG_SMSC9420) += smsc9420.o
> obj-$(CONFIG_SIS190) += sis190.o
> obj-$(CONFIG_SIS900) += sis900.o
> obj-$(CONFIG_R6040) += r6040.o
> @@ -95,7 +93,6 @@ obj-$(CONFIG_NET) += Space.o loopback.o
> obj-$(CONFIG_SEEQ8005) += seeq8005.o
> obj-$(CONFIG_NET_SB1000) += sb1000.o
> obj-$(CONFIG_HP100) += hp100.o
> -obj-$(CONFIG_SMC9194) += smc9194.o
> obj-$(CONFIG_FEC) += fec.o
> obj-$(CONFIG_FEC_MPC52xx) += fec_mpc52xx.o
> ifeq ($(CONFIG_FEC_MPC52xx_MDIO),y)
> @@ -178,9 +175,6 @@ obj-$(CONFIG_IBMVETH) += ibmveth.o
> obj-$(CONFIG_S2IO) += s2io.o
> obj-$(CONFIG_VXGE) += vxge/
> obj-$(CONFIG_MYRI10GE) += myri10ge/
> -obj-$(CONFIG_SMC91X) += smc91x.o
> -obj-$(CONFIG_SMC911X) += smc911x.o
> -obj-$(CONFIG_SMSC911X) += smsc911x.o
> obj-$(CONFIG_PXA168_ETH) += pxa168_eth.o
> obj-$(CONFIG_BFIN_MAC) += bfin_mac.o
> obj-$(CONFIG_DM9000) += dm9000.o
> @@ -227,7 +221,6 @@ obj-$(CONFIG_NETCONSOLE) += netconsole.o
>
> obj-$(CONFIG_FS_ENET) += fs_enet/
>
> -obj-$(CONFIG_NETXEN_NIC) += netxen/
> obj-$(CONFIG_NIU) += niu.o
> obj-$(CONFIG_VIRTIO_NET) += virtio_net.o
> obj-$(CONFIG_SFC) += sfc/
> diff --git a/drivers/net/ethernet/8390/Kconfig b/drivers/net/ethernet/8390/Kconfig
> index 072c641..1c48e4f 100644
> --- a/drivers/net/ethernet/8390/Kconfig
> +++ b/drivers/net/ethernet/8390/Kconfig
> @@ -262,22 +262,9 @@ config STNIC
>
> If unsure, say N.
>
> -config NET_VENDOR_SMC
> - bool "Western Digital/SMC cards"
> - depends on NET_VENDOR_8390 && (ISA || MCA || EISA || MAC)
> - ---help---
> - If you have a network (Ethernet) card belonging to this class, say Y
> - and read the Ethernet-HOWTO, available from
> - <http://www.tldp.org/docs.html#howto>.
> -
> - Note that the answer to this question doesn't directly affect the
> - kernel: saying N will just cause the configurator to skip all
> - the questions about Western Digital cards. If you say Y, you will be
> - asked for your specific card in the following questions.
> -
> config ULTRAMCA
> tristate "SMC Ultra MCA support"
> - depends on NET_VENDOR_SMC && MCA
> + depends on NET_VENDOR_8390 && MCA
> select CRC32
> ---help---
> If you have a network (Ethernet) card of this type and are running
> @@ -289,7 +276,7 @@ config ULTRAMCA
>
> config ULTRA
> tristate "SMC Ultra support"
> - depends on NET_VENDOR_SMC && ISA
> + depends on NET_VENDOR_8390 && ISA
> select CRC32
> ---help---
> If you have a network (Ethernet) card of this type, say Y and read
> @@ -308,7 +295,7 @@ config ULTRA
>
> config ULTRA32
> tristate "SMC Ultra32 EISA support"
> - depends on NET_VENDOR_SMC && EISA
> + depends on NET_VENDOR_8390 && EISA
> select CRC32
> ---help---
> If you have a network (Ethernet) card of this type, say Y and read
> @@ -320,7 +307,7 @@ config ULTRA32
>
> config WD80x3
> tristate "WD80*3 support"
> - depends on NET_VENDOR_SMC && ISA
> + depends on NET_VENDOR_8390 && ISA
> select CRC32
> ---help---
> If you have a network (Ethernet) card of this type, say Y and read
> diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
> index ab591bb..ed5836c 100644
> --- a/drivers/net/ethernet/Kconfig
> +++ b/drivers/net/ethernet/Kconfig
> @@ -18,5 +18,6 @@ source "drivers/net/ethernet/broadcom/Kconfig"
> source "drivers/net/ethernet/chelsio/Kconfig"
> source "drivers/net/ethernet/intel/Kconfig"
> source "drivers/net/ethernet/qlogic/Kconfig"
> +source "drivers/net/ethernet/smsc/Kconfig"
>
> endif # ETHERNET
> diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
> index d8cf120..983fd27 100644
> --- a/drivers/net/ethernet/Makefile
> +++ b/drivers/net/ethernet/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_NET_VENDOR_BROADCOM) += broadcom/
> obj-$(CONFIG_NET_VENDOR_CHELSIO) += chelsio/
> obj-$(CONFIG_NET_VENDOR_INTEL) += intel/
> obj-$(CONFIG_NET_VENDOR_QLOGIC) += qlogic/
> +obj-$(CONFIG_NET_VENDOR_SMSC) += smsc/
> diff --git a/drivers/net/ethernet/smsc/Kconfig b/drivers/net/ethernet/smsc/Kconfig
> new file mode 100644
> index 0000000..dbb3069
> --- /dev/null
> +++ b/drivers/net/ethernet/smsc/Kconfig
> @@ -0,0 +1,128 @@
> +#
> +# Western Digital/SMC network device configuration
> +#
> +
> +config NET_VENDOR_SMSC
> + bool "SMC (SMSC)/Western Digital devices"
> + depends on ARM || ISA || MAC || ARM || MIPS || M32R || SUPERH || \
> + BLACKFIN || MN10300 || COLDFIRE || PCI || PCMCIA
> + ---help---
> + If you have a network (Ethernet) card belonging to this class, say Y
> + and read the Ethernet-HOWTO, available from
> + <http://www.tldp.org/docs.html#howto>.
> +
> + Note that the answer to this question doesn't directly affect the
> + kernel: saying N will just cause the configurator to skip all
> + the questions about SMC/Western Digital cards. If you say Y, you will
> + be asked for your specific card in the following questions.
> +
> +config SMC9194
> + tristate "SMC 9194 support"
> + depends on NET_VENDOR_SMSC && (ISA || MAC && BROKEN)
> + select CRC32
> + ---help---
> + This is support for the SMC9xxx based Ethernet cards. Choose this
> + option if you have a DELL laptop with the docking station, or
> + another SMC9192/9194 based chipset. Say Y if you want it compiled
> + into the kernel, and read the file
> + <file:Documentation/networking/smc9.txt> and the Ethernet-HOWTO,
> + available from <http://www.tldp.org/docs.html#howto>.
> +
> + To compile this driver as a module, choose M here. The module
> + will be called smc9194.
> +
> +config SMC91X
> + tristate "SMC 91C9x/91C1xxx support"
> + select CRC32
> + select MII
> + depends on NET_VENDOR_SMSC && (ARM || M32R || SUPERH || \
> + MIPS || BLACKFIN || MN10300 || COLDFIRE)
> + ---help---
> + This is a driver for SMC's 91x series of Ethernet chipsets,
> + including the SMC91C94 and the SMC91C111. Say Y if you want it
> + compiled into the kernel, and read the file
> + <file:Documentation/networking/smc9.txt> and the Ethernet-HOWTO,
> + available from <http://www.tldp.org/docs.html#howto>.
> +
> + This driver is also available as a module ( = code which can be
> + inserted in and removed from the running kernel whenever you want).
> + The module will be called smc91x. If you want to compile it as a
> + module, say M here and read <file:Documentation/kbuild/modules.txt>.
> +
> +config PCMCIA_SMC91C92
> + tristate "SMC 91Cxx PCMCIA support"
> + depends NET_VENDOR_SMSC && PCMCIA
> + select CRC32
> + select MII
> + ---help---
> + Say Y here if you intend to attach an SMC 91Cxx compatible PCMCIA
> + (PC-card) Ethernet or Fast Ethernet card to your computer.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called smc91c92_cs. If unsure, say N.
> +
> +config EPIC100
> + tristate "SMC EtherPower II"
> + depends on NET_VENDOR_SMSC && PCI
> + select CRC32
> + select MII
> + ---help---
> + This driver is for the SMC EtherPower II 9432 PCI Ethernet NIC,
> + which is based on the SMC83c17x (EPIC/100).
> + More specific information and updates are available from
> + <http://www.scyld.com/network/epic100.html>.
> +
> +config SMC911X
> + tristate "SMSC LAN911[5678] support"
> + select CRC32
> + select MII
> + depends on NET_VENDOR_SMSC && (ARM || SUPERH || MN10300)
> + ---help---
> + This is a driver for SMSC's LAN911x series of Ethernet chipsets
> + including the new LAN9115, LAN9116, LAN9117, and LAN9118.
> + Say Y if you want it compiled into the kernel,
> + and read the Ethernet-HOWTO, available from
> + <http://www.tldp.org/docs.html#howto>.
> +
> + This driver is also available as a module. The module will be
> + called smc911x. If you want to compile it as a module, say M
> + here and read <file:Documentation/kbuild/modules.txt>
> +
> +config SMSC911X
> + tristate "SMSC LAN911x/LAN921x families embedded ethernet support"
> + depends on NET_VENDOR_SMSC && (ARM || SUPERH || BLACKFIN || \
> + MIPS || MN10300)
> + select CRC32
> + select MII
> + select PHYLIB
> + ---help---
> + Say Y here if you want support for SMSC LAN911x and LAN921x families
> + of ethernet controllers.
> +
> + To compile this driver as a module, choose M here and read
> + <file:Documentation/networking/net-modules.txt>. The module
> + will be called smsc911x.
> +
> +config SMSC911X_ARCH_HOOKS
> + def_bool n
> + depends on SMSC911X
> + ---help---
> + If the arch enables this, it allows the arch to implement various
> + hooks for more comprehensive interrupt control and also to override
> + the source of the MAC address.
> +
> +config SMSC9420
> + tristate "SMSC LAN9420 PCI ethernet adapter support"
> + depends on NET_VENDOR_SMSC && PCI
> + select CRC32
> + select PHYLIB
> + select SMSC_PHY
> + ---help---
> + This is a driver for SMSC's LAN9420 PCI ethernet adapter.
> + Say Y if you want it compiled into the kernel,
> + and read the Ethernet-HOWTO, available from
> + <http://www.tldp.org/docs.html#howto>.
> +
> + This driver is also available as a module. The module will be
> + called smsc9420. If you want to compile it as a module, say M
> + here and read <file:Documentation/kbuild/modules.txt>
> diff --git a/drivers/net/ethernet/smsc/Makefile b/drivers/net/ethernet/smsc/Makefile
> new file mode 100644
> index 0000000..f3438de
> --- /dev/null
> +++ b/drivers/net/ethernet/smsc/Makefile
> @@ -0,0 +1,11 @@
> +#
> +# Makefile for the SMSC network device drivers.
> +#
> +
> +obj-$(CONFIG_SMC9194) += smc9194.o
> +obj-$(CONFIG_SMC91X) += smc91x.o
> +obj-$(CONFIG_PCMCIA_SMC91C92) += smc91c92_cs.o
> +obj-$(CONFIG_EPIC100) += epic100.o
> +obj-$(CONFIG_SMSC9420) += smsc9420.o
> +obj-$(CONFIG_SMC911X) += smc911x.o
> +obj-$(CONFIG_SMSC911X) += smsc911x.o
> diff --git a/drivers/net/epic100.c b/drivers/net/ethernet/smsc/epic100.c
> similarity index 100%
> rename from drivers/net/epic100.c
> rename to drivers/net/ethernet/smsc/epic100.c
> diff --git a/drivers/net/smc911x.c b/drivers/net/ethernet/smsc/smc911x.c
> similarity index 100%
> rename from drivers/net/smc911x.c
> rename to drivers/net/ethernet/smsc/smc911x.c
> diff --git a/drivers/net/smc911x.h b/drivers/net/ethernet/smsc/smc911x.h
> similarity index 100%
> rename from drivers/net/smc911x.h
> rename to drivers/net/ethernet/smsc/smc911x.h
> diff --git a/drivers/net/smc9194.c b/drivers/net/ethernet/smsc/smc9194.c
> similarity index 100%
> rename from drivers/net/smc9194.c
> rename to drivers/net/ethernet/smsc/smc9194.c
> diff --git a/drivers/net/smc9194.h b/drivers/net/ethernet/smsc/smc9194.h
> similarity index 100%
> rename from drivers/net/smc9194.h
> rename to drivers/net/ethernet/smsc/smc9194.h
> diff --git a/drivers/net/pcmcia/smc91c92_cs.c b/drivers/net/ethernet/smsc/smc91c92_cs.c
> similarity index 100%
> rename from drivers/net/pcmcia/smc91c92_cs.c
> rename to drivers/net/ethernet/smsc/smc91c92_cs.c
> diff --git a/drivers/net/smc91x.c b/drivers/net/ethernet/smsc/smc91x.c
> similarity index 100%
> rename from drivers/net/smc91x.c
> rename to drivers/net/ethernet/smsc/smc91x.c
> diff --git a/drivers/net/smc91x.h b/drivers/net/ethernet/smsc/smc91x.h
> similarity index 100%
> rename from drivers/net/smc91x.h
> rename to drivers/net/ethernet/smsc/smc91x.h
> diff --git a/drivers/net/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
> similarity index 100%
> rename from drivers/net/smsc911x.c
> rename to drivers/net/ethernet/smsc/smsc911x.c
> diff --git a/drivers/net/smsc911x.h b/drivers/net/ethernet/smsc/smsc911x.h
> similarity index 100%
> rename from drivers/net/smsc911x.h
> rename to drivers/net/ethernet/smsc/smsc911x.h
> diff --git a/drivers/net/smsc9420.c b/drivers/net/ethernet/smsc/smsc9420.c
> similarity index 100%
> rename from drivers/net/smsc9420.c
> rename to drivers/net/ethernet/smsc/smsc9420.c
> diff --git a/drivers/net/smsc9420.h b/drivers/net/ethernet/smsc/smsc9420.h
> similarity index 100%
> rename from drivers/net/smsc9420.h
> rename to drivers/net/ethernet/smsc/smsc9420.h
> diff --git a/drivers/net/pcmcia/Kconfig b/drivers/net/pcmcia/Kconfig
> index 72aa257..f5a738f 100644
> --- a/drivers/net/pcmcia/Kconfig
> +++ b/drivers/net/pcmcia/Kconfig
> @@ -31,17 +31,6 @@ config PCMCIA_FMVJ18X
> To compile this driver as a module, choose M here: the module will be
> called fmvj18x_cs. If unsure, say N.
>
> -config PCMCIA_SMC91C92
> - tristate "SMC 91Cxx PCMCIA support"
> - select CRC32
> - select MII
> - help
> - Say Y here if you intend to attach an SMC 91Cxx compatible PCMCIA
> - (PC-card) Ethernet or Fast Ethernet card to your computer.
> -
> - To compile this driver as a module, choose M here: the module will be
> - called smc91c92_cs. If unsure, say N.
> -
> config PCMCIA_XIRC2PS
> tristate "Xircom 16-bit PCMCIA support"
> help
> diff --git a/drivers/net/pcmcia/Makefile b/drivers/net/pcmcia/Makefile
> index c2b8b44..f9c9883 100644
> --- a/drivers/net/pcmcia/Makefile
> +++ b/drivers/net/pcmcia/Makefile
> @@ -4,7 +4,6 @@
>
> # 16-bit client drivers
> obj-$(CONFIG_PCMCIA_FMVJ18X) += fmvj18x_cs.o
> -obj-$(CONFIG_PCMCIA_SMC91C92) += smc91c92_cs.o
> obj-$(CONFIG_PCMCIA_XIRC2PS) += xirc2ps_cs.o
> obj-$(CONFIG_ARCNET_COM20020_CS)+= com20020_cs.o
>
> --
> 1.7.6
>
^ permalink raw reply
* Re: [net-next v2 11/71] ni5010: Move the Racal-Interlan (Micom) driver
From: Andreas Mohr @ 2011-07-31 16:57 UTC (permalink / raw)
To: Jeff Kirsher
Cc: davem, netdev, gospo, sassmann, Jan-Pascal van Best, Andreas Mohr
In-Reply-To: <1312082850-24914-12-git-send-email-jeffrey.t.kirsher@intel.com>
Hi,
On Sat, Jul 30, 2011 at 08:26:30PM -0700, Jeff Kirsher wrote:
> Moves the Racal-Interlan driver into drivers/net/ethernet/racal/ and
> make the necessary Kconfig and Makefile changes.
Acked-by: Andreas Mohr <andi@lisas.de>
---
Sorry, I had intended to reply to the original RFC,
but due to vacation backlog that got swept under the rug.
Since it's a simple move it seems to be fine.
One minor nit, however: since ni5210 (as seen in some other patch)
got moved to its respective NON-racal location (due to using a specific
chipset),
a short Kconfig addition explaining the whereabouts of ni5210
(and perhaps some other OEM chipset Racal cards?) would be useful.
Thank you for the probably long overdue cleanup of drivers/net/
into something more specific and thus much more easy on the eye :)
Andreas Mohr
^ permalink raw reply
* Re: [RFC net-next v2 00/71] Organize/Move of the Ethernet drivers in drivers/net/
From: Jeff Kirsher @ 2011-07-31 19:00 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: netdev@vger.kernel.org
In-Reply-To: <20110731154515.GA3357@p183.telecom.by>
[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]
On Sun, 2011-07-31 at 08:45 -0700, Alexey Dobriyan wrote:
> > drivers/net/{ => ethernet/3com}/3c501.c
>
> I for one appreciate that Linux has short overall directory
> structure. At work we have like 5-6 directories before
> actual code and it sucks very much.
I agree to some degree. I agree that it nice to only have to go 2-3
layers deep to get to code, but it is also not useful to wade through
357 files in a directory.
drivers/net/ is the largest directory under drivers/ and is 2 times
larger than the next largest directory in drivers/. There are 2255
files/directories in /drivers/net/ and majority are Ethernet drivers.
It has gotten to a point where there needed to be an additional level(s)
of organization. So yes, you have to dig a bit deeper (but it is
logical).
drivers/media/ is the next largest at 23 MB with 1526 files.
>
> > have tab-completion actually work
>
> What do you mean?
What I meant was that tab-completion not becoming not useful when you
get >20 results, you usually end up having to type the entire file name
for what you want. It is nice to type 1-2 characters (and then <tab>)
and get back <5 potential or exact results. David actually brought this
up as an advantage to the new directory structure, which I agree with.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [net-next v2 11/71] ni5010: Move the Racal-Interlan (Micom) driver
From: Jeff Kirsher @ 2011-07-31 19:20 UTC (permalink / raw)
To: Andreas Mohr
Cc: davem@davemloft.net, netdev@vger.kernel.org, gospo@redhat.com,
sassmann@redhat.com, Jan-Pascal van Best
In-Reply-To: <20110731165702.GA6334@rhlx01.hs-esslingen.de>
[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]
On Sun, 2011-07-31 at 09:57 -0700, Andreas Mohr wrote:
> Hi,
>
> On Sat, Jul 30, 2011 at 08:26:30PM -0700, Jeff Kirsher wrote:
> > Moves the Racal-Interlan driver into drivers/net/ethernet/racal/ and
> > make the necessary Kconfig and Makefile changes.
>
> Acked-by: Andreas Mohr <andi@lisas.de>
>
> ---
>
> Sorry, I had intended to reply to the original RFC,
> but due to vacation backlog that got swept under the rug.
>
> Since it's a simple move it seems to be fine.
>
> One minor nit, however: since ni5210 (as seen in some other patch)
> got moved to its respective NON-racal location (due to using a specific
> chipset),
> a short Kconfig addition explaining the whereabouts of ni5210
> (and perhaps some other OEM chipset Racal cards?) would be useful.
Sounds good, would you be up for sending my a patch against my tree and
I can fold it into my current patchset? Or do you want to just send a
patch later on? I know what your intention is, I am just not sure how
you would like it to show up in the Kconfig.
My git tree with this patch series applied is:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-organize
>
> Thank you for the probably long overdue cleanup of drivers/net/
> into something more specific and thus much more easy on the eye :)
Thanks, it is nice to hear.
>
> Andreas Mohr
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [net-next v2 35/71] skge/sky2/mv643xx/pxa168: Move the Marvell Ethernet drivers
From: Stephen Hemminger @ 2011-07-31 22:11 UTC (permalink / raw)
To: Jeff Kirsher, Sachin Sanap
Cc: davem, netdev, gospo, sassmann, Zhangfei Gao, Philip Rakity,
Mark Brown, Lennert Buytenhek
In-Reply-To: <1312082850-24914-36-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, 30 Jul 2011 20:26:54 -0700
Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> MARVELL MWIFIEX WIRELESS DRIVER
> @@ -5816,8 +5816,7 @@ SKGE, SKY2 10/100/1000 GIGABIT ETHERNET DRIVERS
> M: Stephen Hemminger <shemminger@linux-foundation.org>
> L: netdev@vger.kernel.org
> S: Maintained
> -F: drivers/net/skge.*
> -F: drivers/net/sky2.*
> +F: drivers/net/ethernet/marvell/sk*
The old SysKonnect fddi driver should probably be moved in there
as well. It is called skfp.c
I don't maintain that one, it is unmaintained.
^ permalink raw reply
* Re: [net-next v2 35/71] skge/sky2/mv643xx/pxa168: Move the Marvell Ethernet drivers
From: Joe Perches @ 2011-07-31 22:27 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jeff Kirsher, Sachin Sanap, davem, netdev, gospo, sassmann,
Zhangfei Gao, Philip Rakity, Mark Brown, Lennert Buytenhek
In-Reply-To: <20110731151116.647e9974@nehalam.ftrdhcpuser.net>
On Sun, 2011-07-31 at 15:11 -0700, Stephen Hemminger wrote:
> On Sat, 30 Jul 2011 20:26:54 -0700
> Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> > MARVELL MWIFIEX WIRELESS DRIVER
> > @@ -5816,8 +5816,7 @@ SKGE, SKY2 10/100/1000 GIGABIT ETHERNET DRIVERS
> > M: Stephen Hemminger <shemminger@linux-foundation.org>
> > L: netdev@vger.kernel.org
> > S: Maintained
> > -F: drivers/net/skge.*
> > -F: drivers/net/sky2.*
> > +F: drivers/net/ethernet/marvell/sk*
> The old SysKonnect fddi driver should probably be moved in there
> as well. It is called skfp.c
fddi isn't ethernet so I think skfp.c should not be moved there.
^ permalink raw reply
* Re: [RFC net-next v2 00/71] Organize/Move of the Ethernet drivers in drivers/net/
From: David Miller @ 2011-08-01 0:42 UTC (permalink / raw)
To: adobriyan; +Cc: jeffrey.t.kirsher, netdev
In-Reply-To: <20110731154515.GA3357@p183.telecom.by>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Sun, 31 Jul 2011 18:45:16 +0300
>> have tab-completion actually work
>
> What do you mean?
Try to type a path down into drivers/net/ then try to use TAB
completion to finish the path to some driver file.
It's painful and you have to give it so much context before it'll do
anything that it completely negates the benefits of TAB completion.
^ permalink raw reply
* Re: [net-next v2 35/71] skge/sky2/mv643xx/pxa168: Move the Marvell Ethernet drivers
From: Jeff Kirsher @ 2011-08-01 2:43 UTC (permalink / raw)
To: Joe Perches
Cc: Stephen Hemminger, Sachin Sanap, davem@davemloft.net,
netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com,
Zhangfei Gao, Philip Rakity, Mark Brown, Lennert Buytenhek
In-Reply-To: <1312151237.11635.5.camel@Joe-Laptop>
[-- Attachment #1: Type: text/plain, Size: 870 bytes --]
On Sun, 2011-07-31 at 15:27 -0700, Joe Perches wrote:
> On Sun, 2011-07-31 at 15:11 -0700, Stephen Hemminger wrote:
> > On Sat, 30 Jul 2011 20:26:54 -0700
> > Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> > > MARVELL MWIFIEX WIRELESS DRIVER
> > > @@ -5816,8 +5816,7 @@ SKGE, SKY2 10/100/1000 GIGABIT ETHERNET DRIVERS
> > > M: Stephen Hemminger <shemminger@linux-foundation.org>
> > > L: netdev@vger.kernel.org
> > > S: Maintained
> > > -F: drivers/net/skge.*
> > > -F: drivers/net/sky2.*
> > > +F: drivers/net/ethernet/marvell/sk*
> > The old SysKonnect fddi driver should probably be moved in there
> > as well. It is called skfp.c
>
> fddi isn't ethernet so I think skfp.c should not be moved there.
>
>
Joe is right, the skfp (fddi) driver would go in driver/net/fddi/, which
is the next set of follow on patches I am working on.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [net-next v2 35/71] skge/sky2/mv643xx/pxa168: Move the Marvell Ethernet drivers
From: Jeff Kirsher @ 2011-08-01 2:35 UTC (permalink / raw)
To: Joe Perches
Cc: Stephen Hemminger, Sachin Sanap, davem@davemloft.net,
netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com,
Zhangfei Gao, Philip Rakity, Mark Brown, Lennert Buytenhek
In-Reply-To: <1312151237.11635.5.camel@Joe-Laptop>
[-- Attachment #1: Type: text/plain, Size: 868 bytes --]
On Sun, 2011-07-31 at 15:27 -0700, Joe Perches wrote:
> On Sun, 2011-07-31 at 15:11 -0700, Stephen Hemminger wrote:
> > On Sat, 30 Jul 2011 20:26:54 -0700
> > Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> > > MARVELL MWIFIEX WIRELESS DRIVER
> > > @@ -5816,8 +5816,7 @@ SKGE, SKY2 10/100/1000 GIGABIT ETHERNET DRIVERS
> > > M: Stephen Hemminger <shemminger@linux-foundation.org>
> > > L: netdev@vger.kernel.org
> > > S: Maintained
> > > -F: drivers/net/skge.*
> > > -F: drivers/net/sky2.*
> > > +F: drivers/net/ethernet/marvell/sk*
> > The old SysKonnect fddi driver should probably be moved in there
> > as well. It is called skfp.c
>
> fddi isn't ethernet so I think skfp.c should not be moved there.
>
>
Joe is right, the skfp (fddi) driver would go in driver/net/fddi/, which
is the next set of follow on patches I am working on.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* RE: [net-next v2 09/71] smsc: Move the SMC (SMSC) drivers
From: Amit Salecha @ 2011-08-01 6:09 UTC (permalink / raw)
To: Jeff Kirsher, David Miller
Cc: netdev, gospo@redhat.com, sassmann@redhat.com, Nicolas Pitre,
Donald Becker, Erik Stahlman, Dustin McIntire, Steve Glendinning,
David Hinds
In-Reply-To: <1312082850-24914-10-git-send-email-jeffrey.t.kirsher@intel.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Jeff Kirsher
> Sent: Sunday, July 31, 2011 8:56 AM
> Subject: [net-next v2 09/71] smsc: Move the SMC (SMSC) drivers
>
> Moves the SMC (SMSC) drivers into drivers/net/ethernet/smsc/ and the
> necessary Kconfig and Makefile changes. Also did some cleanup
> of NET_VENDOR_SMC Kconfig tag for the 8390 based drivers.
>
> CC: Nicolas Pitre <nico@fluxnic.net>
> CC: Donald Becker <becker@scyld.com>
> CC: Erik Stahlman <erik@vt.edu>
> CC: Dustin McIntire <dustin@sensoria.com>
> CC: Steve Glendinning <steve.glendinning@smsc.com>
> CC: David Hinds <dahinds@users.sourceforge.net>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> -config NETXEN_NIC
> - tristate "NetXen Multi port (1/10) Gigabit Ethernet NIC"
> - depends on PCI
> - select FW_LOADER
> - help
> - This enables the support for NetXen's Gigabit Ethernet card.
> -
>
> -obj-$(CONFIG_NETXEN_NIC) += netxen/
> obj-$(CONFIG_NIU) += niu.o
> obj-$(CONFIG_VIRTIO_NET) += virtio_net.o
> obj-$(CONFIG_SFC) += sfc/
I didn't get reason for above netxen_nic changes.
-Amit
^ permalink raw reply
* RE: [net-next v2 09/71] smsc: Move the SMC (SMSC) drivers
From: Jeff Kirsher @ 2011-08-01 6:16 UTC (permalink / raw)
To: Amit Salecha
Cc: David Miller, netdev, gospo@redhat.com, sassmann@redhat.com,
Nicolas Pitre, Donald Becker, Erik Stahlman, Dustin McIntire,
Steve Glendinning, David Hinds
In-Reply-To: <99737F4847ED0A48AECC9F4A1974A4B80FE464E9E5@MNEXMB2.qlogic.org>
[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]
On Sun, 2011-07-31 at 23:09 -0700, Amit Salecha wrote:
> > -----Original Message-----
> > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > owner@vger.kernel.org] On Behalf Of Jeff Kirsher
> > Sent: Sunday, July 31, 2011 8:56 AM
> > Subject: [net-next v2 09/71] smsc: Move the SMC (SMSC) drivers
> >
> > Moves the SMC (SMSC) drivers into drivers/net/ethernet/smsc/ and the
> > necessary Kconfig and Makefile changes. Also did some cleanup
> > of NET_VENDOR_SMC Kconfig tag for the 8390 based drivers.
> >
> > CC: Nicolas Pitre <nico@fluxnic.net>
> > CC: Donald Becker <becker@scyld.com>
> > CC: Erik Stahlman <erik@vt.edu>
> > CC: Dustin McIntire <dustin@sensoria.com>
> > CC: Steve Glendinning <steve.glendinning@smsc.com>
> > CC: David Hinds <dahinds@users.sourceforge.net>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > ---
> > -config NETXEN_NIC
> > - tristate "NetXen Multi port (1/10) Gigabit Ethernet NIC"
> > - depends on PCI
> > - select FW_LOADER
> > - help
> > - This enables the support for NetXen's Gigabit Ethernet card.
> > -
> >
> > -obj-$(CONFIG_NETXEN_NIC) += netxen/
> > obj-$(CONFIG_NIU) += niu.o
> > obj-$(CONFIG_VIRTIO_NET) += virtio_net.o
> > obj-$(CONFIG_SFC) += sfc/
>
> I didn't get reason for above netxen_nic changes.
>
> -Amit
>
Hmm, it looks like changes destined for the previous patch (the QLogic
patch) got applied to this patch. I will clean this up.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH] net: add Documentation/networking/scaling.txt
From: Tom Herbert @ 2011-08-01 6:56 UTC (permalink / raw)
To: rdunlap, linux-doc, davem, netdev; +Cc: willemb
[-- Attachment #1: Type: TEXT/PLAIN, Size: 17646 bytes --]
Describes RSS, RPS, RFS, accelerated RFS, and XPS.
Signed-off-by: Tom Herbert <therbert@google.com>
---
Documentation/networking/scaling.txt | 346 ++++++++++++++++++++++++++++++++++
1 files changed, 346 insertions(+), 0 deletions(-)
create mode 100644 Documentation/networking/scaling.txt
diff --git a/Documentation/networking/scaling.txt b/Documentation/networking/scaling.txt
new file mode 100644
index 0000000..aa51f0f
--- /dev/null
+++ b/Documentation/networking/scaling.txt
@@ -0,0 +1,346 @@
+Scaling in the Linux Networking Stack
+
+
+Introduction
+============
+
+This document describes a set of complementary techniques in the Linux
+networking stack to increase parallelism and improve performance (in
+throughput, latency, CPU utilization, etc.) for multi-processor systems.
+
+The following technologies are described:
+
+ RSS: Receive Side Scaling
+ RPS: Receive Packet Steering
+ RFS: Receive Flow Steering
+ Accelerated Receive Flow Steering
+ XPS: Transmit Packet Steering
+
+
+RSS: Receive Side Scaling
+=========================
+
+Contemporary NICs support multiple receive queues (multi-queue), which
+can be used to distribute packets amongst CPUs for processing. The NIC
+distributes packets by applying a filter to each packet to assign it to
+one of a small number of logical flows. Packets for each flow are
+steered to a separate receive queue, which in turn can be processed by
+separate CPUs. This mechanism is generally known as “Receive-side
+Scaling” (RSS).
+
+The filter used in RSS is typically a hash function over the network or
+transport layer headers-- for example, a 4-tuple hash over IP addresses
+and TCP ports of a packet. The most common hardware implementation of
+RSS uses a 128 entry indirection table where each entry stores a queue
+number. The receive queue for a packet is determined by masking out the
+low order seven bits of the computed hash for the packet (usually a
+Toeplitz hash), taking this number as a key into the indirection table
+and reading the corresponding value.
+
+Some advanced NICs allow steering packets to queues based on
+programmable filters. For example, webserver bound TCP port 80 packets
+can be directed to their own receive queue. Such “n-tuple” filters can
+be configured from ethtool (--config-ntuple).
+
+== RSS Configuration
+
+The driver for a multi-queue capable NIC typically provides a module
+parameter specifying the number of hardware queues to configure. In the
+bnx2x driver, for instance, this parameter is called num_queues. A
+typical RSS configuration would be to have one receive queue for each
+CPU if the device supports enough queues, or otherwise at least one for
+each cache domain at a particular cache level (L1, L2, etc.).
+
+The indirection table of an RSS device, which resolves a queue by masked
+hash, is usually programmed by the driver at initialization. The
+default mapping is to distribute the queues evenly in the table, but the
+indirection table can be retrieved and modified at runtime using ethtool
+commands (--show-rxfh-indir and --set-rxfh-indir). Modifying the
+indirection table could be done to to give different queues different
+relative weights.
+
+== RSS IRQ Configuration
+
+Each receive queue has a separate IRQ associated with it. The NIC
+triggers this to notify a CPU when new packets arrive on the given
+queue. The signaling path for PCIe devices uses message signaled
+interrupts (MSI-X), that can route each interrupt to a particular CPU.
+The active mapping of queues to IRQs can be determined from
+/proc/interrupts. By default, all IRQs are routed to CPU0. Because a
+non-negligible part of packet processing takes place in receive
+interrupt handling, it is advantageous to spread receive interrupts
+between CPUs. To manually adjust the IRQ affinity of each interrupt see
+Documentation/IRQ-affinity. On some systems, the irqbalance daemon is
+running and will try to dynamically optimize this setting.
+
+
+RPS: Receive Packet Steering
+============================
+
+Receive Packet Steering (RPS) is logically a software implementation of
+RSS. Being in software, it is necessarily called later in the datapath.
+Whereas RSS selects the queue and hence CPU that will run the hardware
+interrupt handler, RPS selects the CPU to perform protocol processing
+above the interrupt handler. This is accomplished by placing the packet
+on the desired CPU’s backlog queue and waking up the CPU for processing.
+RPS has some advantages over RSS: 1) it can be used with any NIC, 2)
+software filters can easily be added to handle new protocols, 3) it does
+not increase hardware device interrupt rate (but does use IPIs).
+
+RPS is called during bottom half of the receive interrupt handler, when
+a driver sends a packet up the network stack with netif_rx() or
+netif_receive_skb(). These call the get_rps_cpu() function, which
+selects the queue that should process a packet.
+
+The first step in determining the target CPU for RPS is to calculate a
+flow hash over the packet’s addresses or ports (2-tuple or 4-tuple hash
+depending on the protocol). This serves as a consistent hash of the
+associated flow of the packet. The hash is either provided by hardware
+or will be computed in the stack. Capable hardware can pass the hash in
+the receive descriptor for the packet, this would usually be the same
+hash used for RSS (e.g. computed Toeplitz hash). The hash is saved in
+skb->rx_hash and can be used elsewhere in the stack as a hash of the
+packet’s flow.
+
+Each receive hardware qeueue has associated list of CPUs which can
+process packets received on the queue for RPS. For each received
+packet, an index into the list is computed from the flow hash modulo the
+size of the list. The indexed CPU is the target for processing the
+packet, and the packet is queued to the tail of that CPU’s backlog
+queue. At the end of the bottom half routine, inter-processor interrupts
+(IPIs) are sent to any CPUs for which packets have been queued to their
+backlog queue. The IPI wakes backlog processing on the remote CPU, and
+any queued packets are then processed up the networking stack. Note that
+the list of CPUs can be configured separately for each hardware receive
+queue.
+
+== RPS Configuration
+
+RPS requires a kernel compiled with the CONFIG_RPS flag (on by default
+for smp). Even when compiled in, it is disabled without any
+configuration. The list of CPUs to which RPS may forward traffic can be
+configured for each receive queue using the sysfs file entry:
+
+ /sys/class/net/<dev>/queues/rx-<n>/rps_cpus
+
+This file implements a bitmap of CPUs. RPS is disabled when it is zero
+(the default), in which case packets are processed on the interrupting
+CPU. IRQ-affinity.txt explains how CPUs are assigned to the bitmap.
+
+For a single queue device, a typical RPS configuration would be to set
+the rps_cpus to the CPUs in the same cache domain of the interrupting
+CPU for a queue. If NUMA locality is not an issue, this could also be
+all CPUs in the system. At high interrupt rate, it might wise to exclude
+the interrupting CPU from the map since that already performs much work.
+
+For a multi-queue system, if RSS is configured so that a receive queue
+is mapped to each CPU, then RPS is probably redundant and unnecessary.
+If there are fewer queues than CPUs, then RPS might be beneficial if the
+rps_cpus for each queue are the ones that share the same cache domain as
+the interrupting CPU for the queue.
+
+RFS: Receive Flow Steering
+==========================
+
+While RPS steers packet solely based on hash, and thus generally
+provides good load distribution, it does not take into account
+application locality. This is accomplished by Receive Flow Steering
+(RFS). The goal of RFS is to increase datacache hitrate by steering
+kernel processing of packets to the CPU where the application thread
+consuming the packet is running. RFS relies on the same RPS mechanisms
+to enqueue packets onto the backlog of another CPU and to wake that CPU.
+
+In RFS, packets are not forwarded directly by the value of their hash,
+but the hash is used as index into a flow lookup table. This table maps
+flows to the CPUs where those flows are being processed. The flow hash
+(see RPS section above) is used to calculate the index into this table.
+The CPU recorded in each entry is the one which last processed the flow,
+and if there is not a valid CPU for an entry, then packets mapped to
+that entry are steered using plain RPS.
+
+To avoid out of order packets (ie. when scheduler moves a thread with
+outstanding receive packets on) there are two levels of flow tables used
+by RFS: rps_sock_flow_table and rps_dev_flow_table.
+
+rps_sock_table is a global flow table. Each table value is a CPU index
+and is populated by recvmsg and sendmsg (specifically, inet_recvmsg(),
+inet_sendmsg(), inet_sendpage() and tcp_splice_read()). This table
+contains the *desired* CPUs for flows.
+
+rps_dev_flow_table is specific to each hardware receive queue of each
+device. Each table value stores a CPU index and a counter. The CPU
+index represents the *current* CPU that is assigned to processing the
+matching flows.
+
+The counter records the length of this CPU's backlog when a packet in
+this flow was last enqueued. Each backlog queue has a head counter that
+is incremented on dequeue. A tail counter is computed as head counter +
+queue length. In other words, the counter in rps_dev_flow_table[i]
+records the last element in flow i that has been enqueued onto the
+currently designated CPU for flow i (of course, entry i is actually
+selected by hash and multiple flows may hash to the same entry i).
+
+And now the trick for avoiding out of order packets: when selecting the
+CPU for packet processing (from get_rps_cpu()) the rps_sock_flow table
+and the rps_dev_flow table of the queue that the packet was received on
+are compared. If the desired CPU for the flow (found in the
+rps_sock_flow table) matches the current CPU (found in the rps_dev_flow
+table), the packet is enqueud onto that CPU’s backlog. If they differ,
+the current cpu is updated to match the desired CPU if one of the
+following is true:
+
+- The current CPU's queue head counter >= the recorded tail counter
+ value in rps_dev_flow[i]
+- The current CPU is unset (equal to NR_CPUS)
+- The current CPU is offline
+
+After this check, the packet is sent to the (possibly updated) current
+CPU. These rules aim to ensure that a flow only moves to a new CPU when
+there are no packets outstanding on the old CPU, as the outstanding
+packets could arrive later than those about to be processed on the new
+CPU.
+
+== RFS Configuration
+
+RFS is only available if the kernel flag CONFIG_RFS is enabled (on by
+default for smp). The functionality is disabled without any
+configuration. The number of entries in the global flow table is set
+through:
+
+ /proc/sys/net/core/rps_sock_flow_entries
+
+The number of entries in the per queue flow table are set through:
+
+ /sys/class/net/<dev>/queues/tx-<n>/rps_flow_cnt
+
+Both of these need to be set before RFS is enabled for a receive queue.
+Values for both of these are rounded up to the nearest power of two. The
+suggested flow count depends on the expected number active connections
+at any given time, which may be significantly less than the number of
+open connections. We have found that a value of 32768 for
+rps_sock_flow_entries works fairly well on a moderately loaded server.
+
+For a single queue device, the rps_flow_cnt value for the single queue
+would normally be configured to the same value as rps_sock_flow_entries.
+For a multi-queue device, the rps_flow_cnt for each queue might be
+configured as rps_sock_flow_entries / N, where N is the number of
+queues. So for instance, if rps_flow_entries is set to 32768 and there
+are 16 configured receive queues, rps_flow_cnt for each queue might be
+configured as 2048.
+
+
+Accelerated RFS
+===============
+
+Accelerated RFS is to RFS what RSS is to RPS: a hardware-accelerated
+load balancing mechanism that uses soft state to steer flows based on
+where the thread consuming the packets of each flow is running.
+Accelerated RFS should perform better than RFS since packets are sent
+directly to a CPU local to the thread consuming the data. The target CPU
+will either be the same CPU where the application runs, or at least a
+CPU which is local to the application thread’s CPU in the cache
+hierarchy.
+
+To enable accelerated RFS, the networking stack calls the
+ndo_rx_flow_steer driver function to communicate the desired hardware
+queue for packets matching a particular flow. The network stack
+automatically calls this function every time a flow entry in
+rps_dev_flow_table is updated. The driver in turn uses a device specific
+method to program the NIC to steer the packets.
+
+The hardware queue for a flow is derived from the CPU recorded in
+rps_dev_flow_table. The stack consults a CPU to hardware queue map which
+is maintained by the NIC driver. This is an autogenerated reverse map of
+the IRQ affinity table shown by /proc/interrupts. Drivers can use
+functions in the cpu_rmap (“cpu affinitiy reverse map”) kernel library
+to populate the map. For each CPU, the corresponding queue in the map is
+set to be one whose processing CPU is closest in cache locality.
+
+== Accelerated RFS Configuration
+
+Accelerated RFS is only available if the kernel is compiled with
+CONFIG_RFS_ACCEL and support is provided by the NIC device and driver.
+It also requires that ntuple filtering is enabled via ethtool. The map
+of CPU to queues is automatically deduced from the IRQ affinities
+configured for each receive queue by the driver, so no additional
+configuration should be necessary.
+
+XPS: Transmit Packet Steering
+=============================
+
+Transmit Packet Steering is a mechanism for intelligently selecting
+which transmit queue to use when transmitting a packet on a multi-queue
+device. To accomplish this, a mapping from CPU to hardware queue(s) is
+recorded. The goal of this mapping is usually to assign queues
+exclusively to a subset of CPUs, where the transmit completions for
+these queues are processed on a CPU within this set. This choice
+provides two benefits. First, contention on the device queue lock is
+significantly reduced since fewer CPUs contend for the same queue
+(contention can be eliminated completely if each CPU has its own
+transmit queue). Secondly, cache miss rate on transmit completion is
+reduced, in particular for data cache lines that hold the sk_buff
+structures.
+
+XPS is configured per transmit queue by setting a bitmap of CPUs that
+may use that queue to transmit. The reverse mapping, from CPUs to
+transmit queues, is computed and maintained for each network device.
+When transmitting the first packet in a flow, the function
+get_xps_queue() is called to select a queue. This function uses the ID
+of the running CPU as a key into the CPU to queue lookup table. If the
+ID matches a single queue, that is used for transmission. If multiple
+queues match, one is selected by using the flow hash to compute an index
+into the set.
+
+The queue chosen for transmitting a particular flow is saved in the
+corresponding socket structure for the flow (e.g. a TCP connection).
+This transmit queue is used for subsequent packets sent on the flow to
+prevent out of order (ooo) packets. The choice also amortizes the cost
+of calling get_xps_queues() over all packets in the connection. To avoid
+ooo packets, the queue for a flow can subsequently only be changed if
+skb->ooo_okay is set for a packet in the flow. This flag indicates that
+there are no outstanding packets in the flow, so the transmit queue can
+change without the risk of generating out of order packets. The
+transport layer is responsible for setting ooo_okay appropriately. TCP,
+for instance, sets the flag when all data for a connection has been
+acknowledged.
+
+
+== XPS Configuration
+
+XPS is only available if the kernel flag CONFIG_XPS is enabled (on by
+default for smp). The functionality is disabled without any
+configuration, in which case the the transmit queue for a packet is
+selected by using a flow hash as an index into the set of all transmit
+queues for the device. To enable XPS, the bitmap of CPUs that may use a
+transmit queue is configured using the sysfs file entry:
+
+/sys/class/net/<dev>/queues/tx-<n>/xps_cpus
+
+XPS is disabled when it is zero (the default). IRQ-affinity.txt explains
+how CPUs are assigned to the bitmap.
+
+For a network device with a single transmission queue, XPS configuration
+has no effect, since there is no choice in this case. In a multi-queue
+system, XPS is usually configured so that each CPU maps onto one queue.
+If there are as many queues as there are CPUs in the system, then each
+queue can also map onto one CPU, resulting in exclusive pairings that
+experience no contention. If there are fewer queues than CPUs, then the
+best CPUs to share a given queue are probably those that share the cache
+with the CPU that processes transmit completions for that queue
+(transmit interrupts).
+
+
+Further Information
+===================
+RPS and RFS were introduced in kernel 2.6.35. XPS was incorporated into
+2.6.38. Original patches were submitted by Tom Herbert
+(therbert@google.com)
+
+
+Accelerated RFS was introduced in 2.6.35. Original patches were
+submitted by Ben Hutchings (bhutchings@solarflare.com)
+
+Authors:
+Tom Herbert (therbert@google.com)
+Willem de Bruijn (willemb@google.com)
+
--
1.7.3.1
^ permalink raw reply related
* Re: net-next-2.6 [PATCH 0/7] dccp: add support for dynamic parameter updates
From: David Miller @ 2011-08-01 7:10 UTC (permalink / raw)
To: gerrit; +Cc: dccp, netdev
In-Reply-To: <1311600996-6712-1-git-send-email-gerrit@erg.abdn.ac.uk>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Mon, 25 Jul 2011 07:36:29 -0600
> I have also placed this in into a fresh (today's) copy of net-next-2.6, on
>
> git://eden-feed.erg.abdn.ac.uk/net-next-2.6 [subtree 'dccp']
I did a test pull and this URL doesn't work:
[davem@dokdo net-next]$ git pull git://eden-feed.erg.abdn.ac.uk/net-next-2.6 dccp
fatal: The remote end hung up unexpectedly
[davem@dokdo net-next]$ git pull git://eden-feed.erg.abdn.ac.uk/net-next-2.6
fatal: The remote end hung up unexpectedly
[davem@dokdo net-next]$
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] be2net: cleanup and refactor stats code
From: David Miller @ 2011-08-01 8:54 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <1311657015-23465-2-git-send-email-sathya.perla@emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Tue, 26 Jul 2011 10:40:14 +0530
> In preparation for 64-bit stats interface, the following cleanups help
> streamline the code:
> 1) made some more rx/tx stats stored by driver 64 bit
> 2) made some HW stas (err/drop counters) stored in be_drv_stats 32 bit to
> keep the code simple as BE provides 32-bit counters only.
> 3) removed duplication of netdev stats in ethtool
> 4) removed some un-necessary stats and fixed some names
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Queued up for net-next
^ 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