Re: [PATCH v3 2/2][BNX2]: Add iSCSI support to BNX2 devices.
Hi Tomo, FUJITA Tomonori wrote: > On Sat, 8 Sep 2007 13:00:36 +0100 > Christoph Hellwig <[EMAIL PROTECTED]> wrote: > >> On Sat, Sep 08, 2007 at 07:32:27AM -0400, Jeff Garzik wrote: >>> FUJITA Tomonori wrote: Yeah, iommu code ignores the lld limitations (the problem is that the lld limitations are in request_queue and iommu code can't access to request_queue). There is no way to tell iommu code about the lld limitations. >>> >>> This fact very much wants fixing. >> >> Absolutely. Unfortunately everyone wastes their time on creating workarounds >> instead of fixing the underlying problem. > > Any ideas on how to fix this? > > I chatted to Jens and James on this last week. > > - we could just copies the lld limitations to device structure. it's > hacky but device structure already has hacky stuff. > > - we could just link device structure to request_queue structure so > that iommu code can see request_queue structure. > > - we could remove the lld limitations in request_queue strucutre and > have a new strucutre (something like struct io_restrictions). then > somehow we could link the new structure with request_queue and device > strucutres. > I'd prefer the latter. These struct io_restrictions could then be used by dm (which has it's own version right now) to merge queue capabilities. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage [EMAIL PROTECTED] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 5/9] net/bonding: Enable IP multicast for bonding IPoIB devices
> > Please get rid of the warning. Make bonding work correctly and allow > enslave/remove > of device when bonding is down. > - > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Hi, I prefer to postpone it till I submit another version of the patches or till after the patches are merged. Anyway, I've added this to the TODO list. thanks MoniS - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ofa-general] [PATCH V6 0/9] net/bonding: ADD IPoIB support for the bonding driver
Jay, I think that all comments to the patches were discussed and handled. If you agree, can you please push then to the networking tree so they will be merged into 2.6.24? This includes the IPoIB patches (agreed with Roland). Note that there are *no* patches to net/core (like in V5). thanks MoniS - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] CAN: Add maintainer entries
This patch adds entries in the CREDITS and MAINTAINERS file for CAN. Signed-off-by: Oliver Hartkopp <[EMAIL PROTECTED]> Signed-off-by: Urs Thuermann <[EMAIL PROTECTED]> --- CREDITS | 16 MAINTAINERS |9 + 2 files changed, 25 insertions(+) Index: net-2.6.24/CREDITS === --- net-2.6.24.orig/CREDITS 2007-09-20 18:48:21.0 +0200 +++ net-2.6.24/CREDITS 2007-09-20 18:49:00.0 +0200 @@ -1331,6 +1331,14 @@ S: 5623 HZ Eindhoven S: The Netherlands +N: Oliver Hartkopp +E: [EMAIL PROTECTED] +W: http://www.volkswagen.de +D: Controller Area Network (network layer core) +S: Brieffach 1776 +S: 38436 Wolfsburg +S: Germany + N: Andrew Haylett E: [EMAIL PROTECTED] D: Selection mechanism @@ -3284,6 +3292,14 @@ S: F-35042 Rennes Cedex S: France +N: Urs Thuermann +E: [EMAIL PROTECTED] +W: http://www.volkswagen.de +D: Controller Area Network (network layer core) +S: Brieffach 1776 +S: 38436 Wolfsburg +S: Germany + N: Jon Tombs E: [EMAIL PROTECTED] W: http://www.esi.us.es/~jon Index: net-2.6.24/MAINTAINERS === --- net-2.6.24.orig/MAINTAINERS 2007-09-20 18:48:21.0 +0200 +++ net-2.6.24/MAINTAINERS 2007-09-20 18:49:00.0 +0200 @@ -975,6 +975,15 @@ L: [EMAIL PROTECTED] S: Maintained +CAN NETWORK LAYER +P: Urs Thuermann +M: [EMAIL PROTECTED] +P: Oliver Hartkopp +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] +W: http://developer.berlios.de/projects/socketcan/ +S: Maintained + CALGARY x86-64 IOMMU P: Muli Ben-Yehuda M: [EMAIL PROTECTED] -- - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] CAN: Add new PF_CAN protocol family, try #8
Hello Dave, hello Patrick,
this is the eigth post of the patch series that adds the PF_CAN
protocol family for the Controller Area Network.
Since our last post we have changed the following:
* Some changes in debug code, following suggestions from Joe Perches:
- Remove dynamically allocated buffer for debug output.
- Use kernel functions for hexdumps.
- Don't interpret printf-style %-sequences in can_debug_cframe().
- Specify the fixed argument "fmt" to DBG() macro and use
GCC ## mechanism to remove , when args is empty.
* Removed CAN_RAW_USER and CAN_BCM_USER Kconfig options following a
suggestion from Patrick.
* Prevent overflow in statistics calculation.
* Minor optimization.
The changes in try #7 were:
* Changes suggested by Patrick:
- protect proto_tab[] by a lock.
- add _rcu to some hlist traversals.
- use printk_ratelimit() for module autoload failures.
- make can_proto_unregister() and can_rx_unregister() return void.
- use return value of can_proto_register() and can_rx_register()
(this also removed a flaw in behavior of raw_bind() and raw_setsockopt()
in case of failure to can_rx_register() their filters).
- call kzalloc() with GFP_KERNEL in case NETDEV_REGISTER.
- use round_jiffies() to calculate expiration times.
- make some variables static and/or __read_mostly.
- in can_create() check for net namespace before auto loading modules.
- add build time check for struct sizes.
- use skb_share_chack() in vcan.
- fixed some comments.
* Typos in documentation as pointed out by Randy Dunlap and Bill Fink.
The changes in try #6 were:
* Update code to work with namespaces in net-2.6.24.
* Remove SET_MODULE_OWNER() from vcan.
The changes in try #5 were:
* Remove slab destructor from calls to kmem_cache_alloc().
* Add comments about types defined in can.h.
* Update comment on vcan loopback module parameter.
* Fix typo in documentation.
The changes in try #4 were:
* Change vcan network driver to use the new RTNL API, as suggested by
Patrick.
* Revert our change to use skb->iif instead of skb->cb. After
discussion with Patrick and Jamal it turned out, our first
implementation was correct.
* Use skb_tail_pointer() instead of skb->tail directly.
* Coding style changes to satisfy linux/scripts/checkpatch.pl.
* Minor changes for 64-bit-cleanliness.
* Minor cleanup of #include's
The changes in try #3 were:
* Use sbk->sk and skb->pkt_type instead of skb->cb to pass loopback
flags and originating socket down to the driver and back to the
receiving socket. Thanks to Patrick McHardy for pointing out our
wrong use of sbk->cb.
* Use skb->iif instead of skb->cb to pass receiving interface from
raw_rcv() and bcm_rcv() up to raw_recvmsg() and bcm_recvmsg().
* Set skb->protocol when sending CAN frames to netdevices.
* Removed struct raw_opt and struct bcm_opt and integrated these
directly into struct raw_sock and bcm_sock resp., like most other
proto implementations do.
* We have found and fixed race conditions between raw_bind(),
raw_{set,get}sockopt() and raw_notifier(). This resulted in
- complete removal of our own notifier list infrastructure in
af_can.c. raw.c and bcm.c now use normal netdevice notifiers.
- removal of ro->lock spinlock. We use lock_sock(sk) now.
- changed deletion of dev_rcv_lists, which are now marked for
deletion in the netdevice notifier in af_can.c and are actually
deleted when all entries have been deleted using can_rx_unregister().
* Follow changes in 2.6.22 (e.g. ktime_t timestamps in skb).
* Removed obsolete code from vcan.c, as pointed out by Stephen Hemminger.
The changes in try #2 were:
* reduced RCU callback overhead when deleting receiver lists (thx to
feedback from Paul E. McKenney).
* eliminated some code duplication in net/can/proc.c.
* renamed slock-29 and sk_lock-29 to slock-AF_CAN and sk_lock-AF_CAN in
net/core/sock.c
* added entry for can.txt in Documentation/networking/00-INDEX
* added error frame definitions in include/linux/can/error.h, which are to
be used by CAN network drivers.
This patch series applies against net-2.6.24 and is derived from Subversion
revision r493 of http://svn.berlios.de/svnroot/repos/socketcan.
It can be found in the directory
http://svn.berlios.de/svnroot/repos/socketcan/trunk/patch-series/.
Thanks very much for your work!
Best regards,
Urs Thuermann
Oliver Hartkopp
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] CAN: Add virtual CAN netdevice driver
This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.
Signed-off-by: Oliver Hartkopp <[EMAIL PROTECTED]>
Signed-off-by: Urs Thuermann <[EMAIL PROTECTED]>
---
drivers/net/Makefile |1
drivers/net/can/Kconfig | 25 +
drivers/net/can/Makefile |5 +
drivers/net/can/vcan.c | 208 +++
net/can/Kconfig |3
5 files changed, 242 insertions(+)
Index: net-2.6.24/drivers/net/Makefile
===
--- net-2.6.24.orig/drivers/net/Makefile2007-09-25 13:28:42.0
+0200
+++ net-2.6.24/drivers/net/Makefile 2007-09-25 13:32:23.0 +0200
@@ -10,6 +10,7 @@
obj-$(CONFIG_CHELSIO_T1) += chelsio/
obj-$(CONFIG_CHELSIO_T3) += cxgb3/
obj-$(CONFIG_EHEA) += ehea/
+obj-$(CONFIG_CAN) += can/
obj-$(CONFIG_BONDING) += bonding/
obj-$(CONFIG_ATL1) += atl1/
obj-$(CONFIG_GIANFAR) += gianfar_driver.o
Index: net-2.6.24/drivers/net/can/Kconfig
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6.24/drivers/net/can/Kconfig 2007-09-25 13:32:23.0 +0200
@@ -0,0 +1,25 @@
+menu "CAN Device Drivers"
+ depends on CAN
+
+config CAN_VCAN
+ tristate "Virtual Local CAN Interface (vcan)"
+ depends on CAN
+ default N
+ ---help---
+ Similar to the network loopback devices, vcan offers a
+ virtual local CAN interface.
+
+ This driver can also be built as a module. If so, the module
+ will be called vcan.
+
+config CAN_DEBUG_DEVICES
+ bool "CAN devices debugging messages"
+ depends on CAN
+ default N
+ ---help---
+ Say Y here if you want the CAN device drivers to produce a bunch of
+ debug messages to the system log. Select this if you are having
+ a problem with CAN support and want to see more of what is going
+ on.
+
+endmenu
Index: net-2.6.24/drivers/net/can/Makefile
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6.24/drivers/net/can/Makefile 2007-09-25 13:32:23.0 +0200
@@ -0,0 +1,5 @@
+#
+# Makefile for the Linux Controller Area Network drivers.
+#
+
+obj-$(CONFIG_CAN_VCAN) += vcan.o
Index: net-2.6.24/drivers/net/can/vcan.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6.24/drivers/net/can/vcan.c 2007-09-25 13:32:23.0 +0200
@@ -0,0 +1,208 @@
+/*
+ * vcan.c - Virtual CAN interface
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, the following disclaimer and
+ *the referenced file 'COPYING'.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2 as distributed in the 'COPYING'
+ * file from the main directory of the linux kernel source.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <[EMAIL PROTECTED]>
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static __initdata const char banner[] =
+
[PATCH 3/7] CAN: Add raw protocol
This patch adds the CAN raw protocol.
Signed-off-by: Oliver Hartkopp <[EMAIL PROTECTED]>
Signed-off-by: Urs Thuermann <[EMAIL PROTECTED]>
---
include/linux/can/raw.h | 31 +
net/can/Kconfig | 11
net/can/Makefile|3
net/can/raw.c | 822
4 files changed, 867 insertions(+)
Index: net-2.6.24/include/linux/can/raw.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6.24/include/linux/can/raw.h 2007-09-25 13:23:05.0 +0200
@@ -0,0 +1,31 @@
+/*
+ * linux/can/raw.h
+ *
+ * Definitions for raw CAN sockets
+ *
+ * Authors: Oliver Hartkopp <[EMAIL PROTECTED]>
+ * Urs Thuermann <[EMAIL PROTECTED]>
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Send feedback to <[EMAIL PROTECTED]>
+ *
+ */
+
+#ifndef CAN_RAW_H
+#define CAN_RAW_H
+
+#include
+
+#define SOL_CAN_RAW (SOL_CAN_BASE + CAN_RAW)
+
+/* for socket options affecting the socket (not the global system) */
+
+enum {
+ CAN_RAW_FILTER = 1, /* set 0 .. n can_filter(s) */
+ CAN_RAW_ERR_FILTER, /* set filter for error frames */
+ CAN_RAW_LOOPBACK, /* local loopback (default:on) */
+ CAN_RAW_RECV_OWN_MSGS /* receive my own msgs (default:off) */
+};
+
+#endif
Index: net-2.6.24/net/can/Kconfig
===
--- net-2.6.24.orig/net/can/Kconfig 2007-09-25 13:14:46.0 +0200
+++ net-2.6.24/net/can/Kconfig 2007-09-25 13:31:06.0 +0200
@@ -16,6 +16,17 @@
If you want CAN support, you should say Y here and also to the
specific driver for your controller(s) below.
+config CAN_RAW
+ tristate "Raw CAN Protocol (raw access with CAN-ID filtering)"
+ depends on CAN
+ default N
+ ---help---
+ The Raw CAN protocol option offers access to the CAN bus via
+ the BSD socket API. You probably want to use the raw socket in
+ most cases where no higher level protocol is being used. The raw
+ socket has several filter options e.g. ID-Masking / Errorframes.
+ To receive/send raw CAN messages, use AF_CAN with protocol CAN_RAW.
+
config CAN_DEBUG_CORE
bool "CAN Core debugging messages"
depends on CAN
Index: net-2.6.24/net/can/Makefile
===
--- net-2.6.24.orig/net/can/Makefile2007-09-25 13:14:46.0 +0200
+++ net-2.6.24/net/can/Makefile 2007-09-25 13:29:23.0 +0200
@@ -4,3 +4,6 @@
obj-$(CONFIG_CAN) += can.o
can-objs := af_can.o proc.o
+
+obj-$(CONFIG_CAN_RAW) += can-raw.o
+can-raw-objs := raw.o
Index: net-2.6.24/net/can/raw.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6.24/net/can/raw.c2007-09-25 13:25:24.0 +0200
@@ -0,0 +1,822 @@
+/*
+ * raw.c - Raw sockets for protocol family CAN
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, the following disclaimer and
+ *the referenced file 'COPYING'.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2 as distributed in the 'COPYING'
+ * file from the main directory of the linux kernel source.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LI
[PATCH 1/7] CAN: Allocate protocol numbers for PF_CAN
This patch adds a protocol/address family number, ARP hardware type, ethernet packet type, and a line discipline number for the SocketCAN implementation. Signed-off-by: Oliver Hartkopp <[EMAIL PROTECTED]> Signed-off-by: Urs Thuermann <[EMAIL PROTECTED]> --- include/linux/if_arp.h |1 + include/linux/if_ether.h |1 + include/linux/socket.h |2 ++ include/linux/tty.h |3 ++- net/core/sock.c |4 ++-- 5 files changed, 8 insertions(+), 3 deletions(-) Index: net-2.6.24/include/linux/if_arp.h === --- net-2.6.24.orig/include/linux/if_arp.h 2007-09-20 18:48:21.0 +0200 +++ net-2.6.24/include/linux/if_arp.h 2007-09-20 18:48:57.0 +0200 @@ -52,6 +52,7 @@ #define ARPHRD_ROSE270 #define ARPHRD_X25 271 /* CCITT X.25 */ #define ARPHRD_HWX25 272 /* Boards with X.25 in firmware */ +#define ARPHRD_CAN 280 /* Controller Area Network */ #define ARPHRD_PPP 512 #define ARPHRD_CISCO 513 /* Cisco HDLC */ #define ARPHRD_HDLCARPHRD_CISCO Index: net-2.6.24/include/linux/if_ether.h === --- net-2.6.24.orig/include/linux/if_ether.h2007-09-20 18:48:21.0 +0200 +++ net-2.6.24/include/linux/if_ether.h 2007-09-20 18:48:57.0 +0200 @@ -90,6 +90,7 @@ #define ETH_P_WAN_PPP 0x0007 /* Dummy type for WAN PPP frames*/ #define ETH_P_PPP_MP0x0008 /* Dummy type for PPP MP frames */ #define ETH_P_LOCALTALK 0x0009 /* Localtalk pseudo type*/ +#define ETH_P_CAN 0x000C /* Controller Area Network */ #define ETH_P_PPPTALK 0x0010 /* Dummy type for Atalk over PPP*/ #define ETH_P_TR_802_2 0x0011 /* 802.2 frames */ #define ETH_P_MOBITEX 0x0015 /* Mobitex ([EMAIL PROTECTED]) */ Index: net-2.6.24/include/linux/socket.h === --- net-2.6.24.orig/include/linux/socket.h 2007-09-20 18:48:21.0 +0200 +++ net-2.6.24/include/linux/socket.h 2007-09-20 18:48:57.0 +0200 @@ -185,6 +185,7 @@ #define AF_PPPOX 24 /* PPPoX sockets*/ #define AF_WANPIPE 25 /* Wanpipe API Sockets */ #define AF_LLC 26 /* Linux LLC*/ +#define AF_CAN 29 /* Controller Area Network */ #define AF_TIPC30 /* TIPC sockets */ #define AF_BLUETOOTH 31 /* Bluetooth sockets*/ #define AF_IUCV32 /* IUCV sockets */ @@ -220,6 +221,7 @@ #define PF_PPPOX AF_PPPOX #define PF_WANPIPE AF_WANPIPE #define PF_LLC AF_LLC +#define PF_CAN AF_CAN #define PF_TIPCAF_TIPC #define PF_BLUETOOTH AF_BLUETOOTH #define PF_IUCVAF_IUCV Index: net-2.6.24/include/linux/tty.h === --- net-2.6.24.orig/include/linux/tty.h 2007-09-20 18:48:21.0 +0200 +++ net-2.6.24/include/linux/tty.h 2007-09-20 18:48:57.0 +0200 @@ -24,7 +24,7 @@ #define NR_PTYSCONFIG_LEGACY_PTY_COUNT /* Number of legacy ptys */ #define NR_UNIX98_PTY_DEFAULT 4096 /* Default maximum for Unix98 ptys */ #define NR_UNIX98_PTY_MAX (1 << MINORBITS) /* Absolute limit */ -#define NR_LDISCS 17 +#define NR_LDISCS 18 /* line disciplines */ #define N_TTY 0 @@ -45,6 +45,7 @@ #define N_SYNC_PPP 14 /* synchronous PPP */ #define N_HCI 15 /* Bluetooth HCI UART */ #define N_GIGASET_M101 16 /* Siemens Gigaset M101 serial DECT adapter */ +#define N_SLCAN17 /* Serial / USB serial CAN Adaptors */ /* * This character is the same as _POSIX_VDISABLE: it cannot be used as Index: net-2.6.24/net/core/sock.c === --- net-2.6.24.orig/net/core/sock.c 2007-09-20 18:48:21.0 +0200 +++ net-2.6.24/net/core/sock.c 2007-09-20 18:48:57.0 +0200 @@ -154,7 +154,7 @@ "sk_lock-AF_ASH" , "sk_lock-AF_ECONET" , "sk_lock-AF_ATMSVC" , "sk_lock-21" , "sk_lock-AF_SNA" , "sk_lock-AF_IRDA" , "sk_lock-AF_PPPOX" , "sk_lock-AF_WANPIPE" , "sk_lock-AF_LLC" , - "sk_lock-27" , "sk_lock-28" , "sk_lock-29" , + "sk_lock-27" , "sk_lock-28" , "sk_lock-AF_CAN" , "sk_lock-AF_TIPC" , "sk_lock-AF_BLUETOOTH", "sk_lock-IUCV", "sk_lock-AF_RXRPC" , "sk_lock-AF_MAX" }; @@ -168,7 +168,7 @@ "slock-AF_ASH" , "slock-AF_ECONET" , "slock-AF_ATMSVC" , "slock-21" , "slock-AF_SNA" , "slock-AF_IRDA" , "slock-AF_PPPOX" , "slock-AF_WANPIPE" , "slock-AF_LLC" , - "slock-27" , "s
[PATCH 4/7] CAN: Add broadcast manager (bcm) protocol
This patch adds the CAN broadcast manager (bcm) protocol.
Signed-off-by: Oliver Hartkopp <[EMAIL PROTECTED]>
Signed-off-by: Urs Thuermann <[EMAIL PROTECTED]>
---
include/linux/can/bcm.h | 65 +
net/can/Kconfig | 13
net/can/Makefile|3
net/can/bcm.c | 1778
4 files changed, 1859 insertions(+)
Index: net-2.6.24/include/linux/can/bcm.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6.24/include/linux/can/bcm.h 2007-09-25 13:31:23.0 +0200
@@ -0,0 +1,65 @@
+/*
+ * linux/can/bcm.h
+ *
+ * Definitions for CAN Broadcast Manager (BCM)
+ *
+ * Author: Oliver Hartkopp <[EMAIL PROTECTED]>
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Send feedback to <[EMAIL PROTECTED]>
+ *
+ */
+
+#ifndef CAN_BCM_H
+#define CAN_BCM_H
+
+/**
+ * struct bcm_msg_head - head of messages to/from the broadcast manager
+ * @opcode:opcode, see enum below.
+ * @flags: special flags, see below.
+ * @count: number of frames to send before changing interval.
+ * @ival1: interval for the first @count frames.
+ * @ival2: interval for the following frames.
+ * @can_id:CAN ID of frames to be sent or received.
+ * @nframes: number of frames appended to the message head.
+ * @frames:array of CAN frames.
+ */
+struct bcm_msg_head {
+ int opcode;
+ int flags;
+ int count;
+ struct timeval ival1, ival2;
+ canid_t can_id;
+ int nframes;
+ struct can_frame frames[0];
+};
+
+enum {
+ TX_SETUP = 1, /* create (cyclic) transmission task */
+ TX_DELETE, /* remove (cyclic) transmission task */
+ TX_READ,/* read properties of (cyclic) transmission task */
+ TX_SEND,/* send one CAN frame */
+ RX_SETUP, /* create RX content filter subscription */
+ RX_DELETE, /* remove RX content filter subscription */
+ RX_READ,/* read properties of RX content filter subscription */
+ TX_STATUS, /* reply to TX_READ request */
+ TX_EXPIRED, /* notification on performed transmissions (count=0) */
+ RX_STATUS, /* reply to RX_READ request */
+ RX_TIMEOUT, /* cyclic message is absent */
+ RX_CHANGED /* updated CAN frame (detected content change) */
+};
+
+#define SETTIMER0x0001
+#define STARTTIMER 0x0002
+#define TX_COUNTEVT 0x0004
+#define TX_ANNOUNCE 0x0008
+#define TX_CP_CAN_ID0x0010
+#define RX_FILTER_ID0x0020
+#define RX_CHECK_DLC0x0040
+#define RX_NO_AUTOTIMER 0x0080
+#define RX_ANNOUNCE_RESUME 0x0100
+#define TX_RESET_MULTI_IDX 0x0200
+#define RX_RTR_FRAME0x0400
+
+#endif /* CAN_BCM_H */
Index: net-2.6.24/net/can/Kconfig
===
--- net-2.6.24.orig/net/can/Kconfig 2007-09-25 13:31:06.0 +0200
+++ net-2.6.24/net/can/Kconfig 2007-09-25 13:31:46.0 +0200
@@ -27,6 +27,19 @@
socket has several filter options e.g. ID-Masking / Errorframes.
To receive/send raw CAN messages, use AF_CAN with protocol CAN_RAW.
+config CAN_BCM
+ tristate "Broadcast Manager CAN Protocol (with content filtering)"
+ depends on CAN
+ default N
+ ---help---
+ The Broadcast Manager offers content filtering, timeout monitoring,
+ sending of RTR-frames and cyclic CAN messages without permanent user
+ interaction. The BCM can be 'programmed' via the BSD socket API and
+ informs you on demand e.g. only on content updates / timeouts.
+ You probably want to use the bcm socket in most cases where cyclic
+ CAN messages are used on the bus (e.g. in automotive environments).
+ To use the Broadcast Manager, use AF_CAN with protocol CAN_BCM.
+
config CAN_DEBUG_CORE
bool "CAN Core debugging messages"
depends on CAN
Index: net-2.6.24/net/can/Makefile
===
--- net-2.6.24.orig/net/can/Makefile2007-09-25 13:29:23.0 +0200
+++ net-2.6.24/net/can/Makefile 2007-09-25 13:31:23.0 +0200
@@ -7,3 +7,6 @@
obj-$(CONFIG_CAN_RAW) += can-raw.o
can-raw-objs := raw.o
+
+obj-$(CONFIG_CAN_BCM) += can-bcm.o
+can-bcm-objs := bcm.o
Index: net-2.6.24/net/can/bcm.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6.24/net/can/bcm.c2007-09-25 13:31:23.0 +0200
@@ -0,0 +1,1778 @@
+/*
+ * bcm.c - Broadcast Manager to filter/send (cyclic) CAN content
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided
[PATCH 7/7] CAN: Add documentation
This patch adds documentation for the PF_CAN protocol family. Signed-off-by: Oliver Hartkopp <[EMAIL PROTECTED]> Signed-off-by: Urs Thuermann <[EMAIL PROTECTED]> --- Documentation/networking/00-INDEX |2 Documentation/networking/can.txt | 634 ++ 2 files changed, 636 insertions(+) Index: net-2.6.24/Documentation/networking/can.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ net-2.6.24/Documentation/networking/can.txt 2007-09-25 13:28:26.0 +0200 @@ -0,0 +1,634 @@ + + +can.txt + +Readme file for the Controller Area Network Protocol Family (aka Socket CAN) + +This file contains + + 1 Overview / What is Socket CAN + + 2 Motivation / Why using the socket API + + 3 Socket CAN concept +3.1 receive lists +3.2 loopback +3.3 network security issues (capabilities) +3.4 network problem notifications + + 4 How to use Socket CAN +4.1 RAW protocol sockets with can_filters (SOCK_RAW) + 4.1.1 RAW socket option CAN_RAW_FILTER + 4.1.2 RAW socket option CAN_RAW_ERR_FILTER + 4.1.3 RAW socket option CAN_RAW_LOOPBACK + 4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS +4.2 Broadcast Manager protocol sockets (SOCK_DGRAM) +4.3 connected transport protocols (SOCK_SEQPACKET) +4.4 unconnected transport protocols (SOCK_DGRAM) + + 5 Socket CAN core module +5.1 can.ko module params +5.2 procfs content +5.3 writing own CAN protocol modules + + 6 CAN network drivers +6.1 general settings +6.2 loopback +6.3 CAN controller hardware filters +6.4 currently supported CAN hardware +6.5 todo + + 7 Credits + + + +1. Overview / What is Socket CAN + + +The socketcan package is an implementation of CAN protocols +(Controller Area Network) for Linux. CAN is a networking technology +which has widespread use in automation, embedded devices, and +automotive fields. While there have been other CAN implementations +for Linux based on character devices, Socket CAN uses the Berkeley +socket API, the Linux network stack and implements the CAN device +drivers as network interfaces. The CAN socket API has been designed +as similar as possible to the TCP/IP protocols to allow programmers, +familiar with network programming, to easily learn how to use CAN +sockets. + +2. Motivation / Why using the socket API + + +There have been CAN implementations for Linux before Socket CAN so the +question arises, why we have started another project. Most existing +implementations come as a device driver for some CAN hardware, they +are based on character devices and provide comparatively little +functionality. Usually, there is only a hardware-specific device +driver which provides a character device interface to send and +receive raw CAN frames, directly to/from the controller hardware. +Queueing of frames and higher-level transport protocols like ISO-TP +have to be implemented in user space applications. Also, most +character-device implementations support only one single process to +open the device at a time, similar to a serial interface. Exchanging +the CAN controller requires employment of another device driver and +often the need for adaption of large parts of the application to the +new driver's API. + +Socket CAN was designed to overcome all of these limitations. A new +protocol family has been implemented which provides a socket interface +to user space applications and which builds upon the Linux network +layer, so to use all of the provided queueing functionality. A device +driver for CAN controller hardware registers itself with the Linux +network layer as a network device, so that CAN frames from the +controller can be passed up to the network layer and on to the CAN +protocol family module and also vice-versa. Also, the protocol family +module provides an API for transport protocol modules to register, so +that any number of transport protocols can be loaded or unloaded +dynamically. In fact, the can core module alone does not provide any +protocol and cannot be used without loading at least one additional +protocol module. Multiple sockets can be opened at the same time, +on different or the same protocol module and they can listen/send +frames on different or the same CAN IDs. Several sockets listening on +the same interface for frames with the same CAN ID are all passed the +same received matching CAN frames. An application wishing to +communicate using a specific transport protocol, e.g. ISO-TP, just +selects that protocol when opening the socket, and then can read and +write application data byte streams, without having to deal with +CAN-IDs, frames, etc. + +Similar functionality visible from user-space
Re: [PATCH 2/7] CAN: Add PF_CAN core module
Em Tue, Sep 25, 2007 at 02:20:31PM +0200, Urs Thuermann escreveu:
> +
> +static void can_sock_destruct(struct sock *sk)
> +{
> + DBG("called for sock %p\n", sk);
> +
> + skb_queue_purge(&sk->sk_receive_queue);
> + if (sk->sk_protinfo)
> + kfree(sk->sk_protinfo);
> +}
Is it really needed to do this sk_protinfo check? You don't use it and
it is going to be removed (only user is one of the HAM radio protocols),
so it would be better to not add any more references to this struct sock
field.
- Arnaldo
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/7] CAN: Add broadcast manager (bcm) protocol
Em Tue, Sep 25, 2007 at 02:20:33PM +0200, Urs Thuermann escreveu:
> This patch adds the CAN broadcast manager (bcm) protocol.
>
> +static void bcm_can_tx(struct bcm_op *op)
> +{
> + skb = alloc_skb(CFSIZ,
> + in_interrupt() ? GFP_ATOMIC : GFP_KERNEL);
We have gfp_any() for this:
[EMAIL PROTECTED] net-2.6.24]$ grep gfp_any net/*/*.[ch]
net/ipv4/tcp.c: tcp_send_active_reset(sk, gfp_any());
net/ipv6/route.c: skb = nlmsg_new(rt6_nlmsg_size(), gfp_any());
net/ipv6/route.c: err = rtnl_notify(skb, pid, RTNLGRP_IPV6_ROUTE,
nlh, gfp_any());
net/netfilter/nfnetlink.c: netlink_broadcast(nfnl, skb, pid, group,
gfp_any());
net/netlink/af_netlink.c: skb = netlink_trim(skb, gfp_any());
[EMAIL PROTECTED] net-2.6.24]$ grep in_interrupt net/*/*.[ch]
net/decnet/dn_route.c: int user_mode = !in_interrupt();
net/decnet/dn_table.c: if (in_interrupt() && net_ratelimit()) {
[EMAIL PROTECTED] net-2.6.24]$
> +static void bcm_send_to_user(struct bcm_op *op, struct bcm_msg_head *head,
> + struct can_frame *frames, int has_timestamp)
> +{
> + struct sk_buff *skb;
> + struct can_frame *firstframe;
> + struct sockaddr_can *addr;
> + struct sock *sk = op->sk;
> + int datalen = head->nframes * CFSIZ;
> + int err;
> +
> + skb = alloc_skb(sizeof(*head) + datalen,
> + in_interrupt() ? GFP_ATOMIC : GFP_KERNEL);
ditto
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] [NET_SCHED] explict hold dev tx lock
On Mon, 2007-24-09 at 16:47 -0700, Waskiewicz Jr, Peter P wrote:
> We should make sure we're symmetric with the locking on enqueue to
> dequeue. If we use the single device queue lock on enqueue, then
> dequeue will also need to check that lock in addition to the individual
> queue lock. The details of this are more trivial than the actual
> dequeue to make it efficient though.
It would be interesting to observe the performance implications.
> The dequeue locking would be pushed into the qdisc itself. This is how
> I had it originally, and it did make the code more complex, but it was
> successful at breaking the heavily-contended queue_lock apart. I have a
> subqueue structure right now in netdev, which only has queue_state (for
> netif_{start|stop}_subqueue). This state is checked in sch_prio right
> now in the dequeue for both prio and rr. My approach is to add a
> queue_lock in that struct, so each queue allocated by the driver would
> have a lock per queue. Then in dequeue, that lock would be taken when
> the skb is about to be dequeued.
more locks implies degraded performance. If only one processor can enter
that region, presumably after acquiring the outer lock , why this
secondary lock per queue?
> The skb->queue_mapping field also maps directly to the queue index
> itself, so it can be unlocked easily outside of the context of the
> dequeue function. The policy would be to use a spin_trylock() in
> dequeue, so that dequeue can still do work if enqueue or another dequeue
> is busy.
So there could be a parallel cpu dequeueing at the same time?
Wouldnt this have implications depending on what the scheduling
algorithm used? If for example i was doing priority queueing i would
want to make sure the highest priority is being dequeued first AND by
all means goes out first to the driver; i dont want a parallell cpu
dequeing a lower prio packet at the same time.
> And the allocation of qdisc queues to device queues is assumed
> to be one-to-one (that's how the qdisc behaves now).
Ok, that brings back the discussion we had; my thinking was something
like dev->hard_prep_xmit() would select the ring and i think you
staticly already map the ring to a qdisc queue. So i dont think
dev->hard_prep_xmit() is useful to you.
In any case, there is nothing the batching patches do that interfere or
prevent you from going the path you intend to. instead of dequeueing one
packet, you dequeue several and instead of sending to the driver one
packet, you send several. And using the xmit_win, you should never ever
have to requeue.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] [NET_SCHED] explict hold dev tx lock
On Mon, 2007-24-09 at 17:14 -0700, Stephen Hemminger wrote: > Since we are redoing this, > is there any way to make the whole TX path > more lockless? The existing model seems to be more of a monitor than > a real locking model. What do you mean it is "more of a monitor"? On the challenge of making it lockless: About every NAPI driver combines the tx prunning with rx polling. If you are dealing with tx resources on receive thread as well as tx thread, _you need_ locking. The only other way we can do avoid it is to separate the rx path interupts from ones on tx related resources; the last NAPI driver that did that was tulip; i think the e1000 for a short period in its life did the same as well. But that has been frowned on and people have evolved away from it. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sb1250-mac: Driver model & phylib update
On Fri, Sep 21, 2007 at 12:44:09PM -0700, Andrew Morton wrote: > > A driver model and phylib update. > > akpm:/usr/src/25> diffstat patches/git-net.patch | tail -n 1 > 1013 files changed, 187667 insertions(+), 23587 deletions(-) > > Sorry, but raising networking patches against Linus's crufty > old mainline tree just isn't viable at present. Out of curiosity: [EMAIL PROTECTED] linux-queue]$ git diff $(git merge-base master v2.6.23-rc8-mm1)..v2.6.23-rc8-mm1 | wc -cl 1046669 31900996 [EMAIL PROTECTED] linux-queue]$ git diff $(git merge-base master v2.6.23-rc8-mm1)..v2.6.23-rc8-mm1 | diffstat | tail -1 6049 files changed, 573635 insertions(+), 207630 deletions(-) [EMAIL PROTECTED] linux-queue]$ We're all a little too productive ;-) Ralf - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
Hello.
In article <[EMAIL PROTECTED]> (at Tue, 25 Sep 2007 14:20:34 +0200), Urs
Thuermann <[EMAIL PROTECTED]> says:
> Index: net-2.6.24/drivers/net/can/vcan.c
> ===
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ net-2.6.24/drivers/net/can/vcan.c 2007-09-25 13:32:23.0 +0200
> @@ -0,0 +1,208 @@
> +/*
> + * vcan.c - Virtual CAN interface
> + *
> + * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions, the following disclaimer and
> + *the referenced file 'COPYING'.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + * 3. Neither the name of Volkswagen nor the names of its contributors
> + *may be used to endorse or promote products derived from this software
> + *without specific prior written permission.
> + *
> + * Alternatively, provided that this notice is retained in full, this
~~
> + * software may be distributed under the terms of the GNU General
> + * Public License ("GPL") version 2 as distributed in the 'COPYING'
> + * file from the main directory of the linux kernel source.
> + *
> + * The provided data structures and external interfaces from this code
> + * are not restricted to be used by modules with a GPL compatible license.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> + * DAMAGE.
> + *
> + * Send feedback to <[EMAIL PROTECTED]>
> + *
> + */
I'm not a lawyer, but the following lines:
| + * Alternatively, provided that this notice is retained in full, this
~~
| + * software may be distributed under the terms of the GNU General
| + * Public License ("GPL") version 2 as distributed in the 'COPYING'
| + * file from the main directory of the linux kernel source.
make this whole licence imcompatible with GPL.
I do think you need to allow people to select GPLv2 only.
--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] CAN: Add PF_CAN core module
Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> writes: > > + skb_queue_purge(&sk->sk_receive_queue); > > + if (sk->sk_protinfo) > > + kfree(sk->sk_protinfo); > > +} > > Is it really needed to do this sk_protinfo check? Thanks for finding this. This is from 2.6.12 times or so. We have other CAN protocol (which we are not allowed to put under GPL) implemenatations which still use the protinfo field. But we should change those and I will delete this check. urs - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/7] CAN: Add broadcast manager (bcm) protocol
Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> writes: > > + skb = alloc_skb(CFSIZ, > > + in_interrupt() ? GFP_ATOMIC : GFP_KERNEL); > > We have gfp_any() for this: Ah, ok. That looks better. Applied. urs - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
YOSHIFUJI Hideaki / È£ÑÀ <[EMAIL PROTECTED]> writes:
> I'm not a lawyer, but the following lines:
>
> | + * Alternatively, provided that this notice is retained in full, this
> ~~
> | + * software may be distributed under the terms of the GNU General
> | + * Public License ("GPL") version 2 as distributed in the 'COPYING'
> | + * file from the main directory of the linux kernel source.
>
> make this whole licence imcompatible with GPL.
I'm no lawyer at all, either. And also Oliver is not, but he has
carried out the fights with our company lawyers. Maybe he can say
something about whether we can change this.
> I do think you need to allow people to select GPLv2 only.
The sentence you cite *does* allow distribution under GPLv2 only. And
I think I have often read the restriction to retain such licences in
full in GPLv2 code. Is that really incompatible?
urs
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
Urs Thuermann wrote:
> YOSHIFUJI Hideaki / È£ÑÀ <[EMAIL PROTECTED]> writes:
>
>
>>I'm not a lawyer, but the following lines:
>>
>>| + * Alternatively, provided that this notice is retained in full, this
>> ~~
>>| + * software may be distributed under the terms of the GNU General
>>| + * Public License ("GPL") version 2 as distributed in the 'COPYING'
>>| + * file from the main directory of the linux kernel source.
>>
>>make this whole licence imcompatible with GPL.
>
>
> I'm no lawyer at all, either. And also Oliver is not, but he has
> carried out the fights with our company lawyers. Maybe he can say
> something about whether we can change this.
>
>
>>I do think you need to allow people to select GPLv2 only.
>
>
> The sentence you cite *does* allow distribution under GPLv2 only. And
> I think I have often read the restriction to retain such licences in
> full in GPLv2 code. Is that really incompatible?
Not that it necessarily means its valid, but there are multiple
files in the kernel that carry the exact same term:
arch/x86_64/crypto/aes.c
arch/i386/crypto/aes.c
crypto/gf128mul.c
crypto/aes.c
drivers/net/ppp_mppe.c
drivers/crypto/padlock-aes.c
include/crypto/b128ops.h
include/crypto/gf128mul.h
OTOH I tend to agree with Yoshifuji that once someone has
selected the GPL and has made enough changes that no parts
"can be reasonably considered independent and separate works",
it seems like an additional and confusing restriction to be
forced to retain ineffective licensing terms.
But since I'm not a lawyer either I'm going to refrain from
further speculation :)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 0/9] net/bonding: ADD IPoIB support for the bonding driver
ACK patches 3 - 9. Roland, are you comfortable with the IB changes in patches 1 and 2? Jeff, when Roland acks patches 1 and 2, please apply all 9. -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] Moni Shoua <[EMAIL PROTECTED]> wrote: >This patch series is the sixth version (see below link to V5) of the >suggested changes to the bonding driver so it would be able to support >non ARPHRD_ETHER netdevices for its High-Availability (active-backup) mode. > >Patches 1-8 were originally submitted in V5 and patch 9 is an addition by Jay. > > >Major changes from the previous version: > > >1. Remove the patches to net/core. Bonding will use the NETDEV_GOING_DOWN >notification > instead of NETDEV_CHANGE+IFF_SLAVE_DETACH. This reduces the amount of > patches from 11 > to 9. > >Links to earlier discussion: > > >1. A discussion in netdev about bonding support for IPoIB. >http://lists.openwall.net/netdev/2006/11/30/46 > >2. V5 series >http://lists.openfabrics.org/pipermail/general/2007-September/040996.html > >- >To unsubscribe from this list: send the line "unsubscribe netdev" in >the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] [NET_SCHED] explict hold dev tx lock
On Tue, 25 Sep 2007 09:15:38 -0400 jamal <[EMAIL PROTECTED]> wrote: > On Mon, 2007-24-09 at 17:14 -0700, Stephen Hemminger wrote: > > > Since we are redoing this, > > is there any way to make the whole TX path > > more lockless? The existing model seems to be more of a monitor than > > a real locking model. > http://en.wikipedia.org/wiki/Monitor_(synchronization) > What do you mean it is "more of a monitor"? The transmit code path is locked as a code region, rather than just object locking on the transmit queue or other fine grained object. This leads to moderately long lock hold times when multiple qdisc's and classification is being done. > > On the challenge of making it lockless: > About every NAPI driver combines the tx prunning with rx polling. If you > are dealing with tx resources on receive thread as well as tx thread, > _you need_ locking. The only other way we can do avoid it is to separate > the rx path interupts from ones on tx related resources; the last NAPI > driver that did that was tulip; i think the e1000 for a short period in > its life did the same as well. But that has been frowned on and people > have evolved away from it. If we went to finer grain locking it would also mean changes to all network devices using the new locking model. My assumption is that we would use something like the features flag to do the transition for backward compatibility. Take this as a purely "what if" or "it would be nice if" kind of suggestion not a requirement or some grand plan. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] CAN: Add PF_CAN core module
On 25 Sep 2007 15:24:33 +0200 Urs Thuermann <[EMAIL PROTECTED]> wrote: > Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> writes: > > > > + skb_queue_purge(&sk->sk_receive_queue); > > > + if (sk->sk_protinfo) > > > + kfree(sk->sk_protinfo); > > > +} > > > > Is it really needed to do this sk_protinfo check? > > Thanks for finding this. This is from 2.6.12 times or so. We have > other CAN protocol (which we are not allowed to put under GPL) > implemenatations which still use the protinfo field. But we should > change those and I will delete this check. > > urs Then please make all exported symbols marked EXPORT_SYMBOL_GPL to make sure that the other CAN protocol can not reuse your infrastructure. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH: 2.6.13-15-SMP 3/3] network: concurrently runsoftirqnetwork code on SMP
Jamal,
You pointed out a key point: it's NOT acceptable if massive packet re-ordering
couldn¡¯t be avoided.
I debugged function tcp_ofo_queue in net/ipv4/tcp_input.c & monitored
out_of_order_queue, found that re-ordering
becomes unacceptable with the softirq load grows.
It's simple to avoid out-of-order packets by changing random dispatch into
dispatch based on source ip address.
e.g. cpu = iph->saddr % nr_cpus. while cpu is like a hash entry.
Considering that BS patch is mainly used on server with many incoming
connections,
dispatch by IP should balance CPU load well.
The test is under way, it's not bad so far.
The queue spin_lock seems not cost much.
Below is the bcpp beautified module code. Last time code mess is caused by
outlook express which killed tabs.
Thanks.
John Ye
/*
* BOTTOM_SOFTIRQ_NET
* An implementation of bottom softirq concurrent execution on SMP
* This is implemented by splitting current net softirq into top
half
* and bottom half, dispatch the bottom half to each cpu's
workqueue.
* Hopefully, it can raise the throughput of NIC when running
iptalbes
* on SMP machine.
*
* Version:$Id: bs_smp.c, v 2.6.13-15 for kernel 2.6.13-15-smp
*
* Authors:John Ye & QianYu Ye, 2007.08.27
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
static spinlock_t *p_ptype_lock;
static struct list_head *p_ptype_base;/* 16 way hashed list */
int (*Pip_options_rcv_srr)(struct sk_buff *skb);
int (*Pnf_rcv_postxfrm_nonlocal)(struct sk_buff *skb);
struct ip_rt_acct *ip_rt_acct;
struct ipv4_devconf *Pipv4_devconf;
#define ipv4_devconf (*Pipv4_devconf)
//#define ip_rt_acct Pip_rt_acct
#define ip_options_rcv_srr Pip_options_rcv_srr
#define nf_rcv_postxfrm_nonlocal Pnf_rcv_postxfrm_nonlocal
//extern int nf_rcv_postxfrm_local(struct sk_buff *skb);
//extern int ip_options_rcv_srr(struct sk_buff *skb);
static struct workqueue_struct **Pkeventd_wq;
#define keventd_wq (*Pkeventd_wq)
#define INSERT_CODE_HERE
static inline int ip_rcv_finish(struct sk_buff *skb)
{
struct net_device *dev = skb->dev;
struct iphdr *iph = skb->nh.iph;
int err;
/*
* Initialise the virtual path cache for the packet. It describes
* how the packet travels inside Linux networking.
*/
if (skb->dst == NULL)
{
if ((err = ip_route_input(skb, iph->daddr, iph->saddr,
iph->tos, dev)))
{
if (err == -EHOSTUNREACH)
IP_INC_STATS_BH(IPSTATS_MIB_INADDRERRORS);
goto drop;
}
}
if (nf_xfrm_nonlocal_done(skb))
return nf_rcv_postxfrm_nonlocal(skb);
#ifdef CONFIG_NET_CLS_ROUTE
if (skb->dst->tclassid)
{
struct ip_rt_acct *st = ip_rt_acct + 256*smp_processor_id();
u32 idx = skb->dst->tclassid;
st[idx&0xFF].o_packets++;
st[idx&0xFF].o_bytes+=skb->len;
st[(idx>>16)&0xFF].i_packets++;
st[(idx>>16)&0xFF].i_bytes+=skb->len;
}
#endif
if (iph->ihl > 5)
{
struct ip_options *opt;
/* It looks as overkill, because not all
IP options require packet mangling.
But it is the easiest for now, especially taking
into account that combination of IP options
and running sniffer is extremely rare condition.
--ANK (980813)
*/
if (skb_cow(skb, skb_headroom(skb)))
{
IP_INC_STATS_BH(IPSTATS_MIB_INDISCARDS);
goto drop;
}
iph = skb->nh.iph;
if (ip_options_compile(NULL, skb))
goto inhdr_error;
opt = &(IPCB(skb)->opt);
if (opt->srr)
{
struct in_device *in_dev = in_dev_get(dev);
if (in_dev)
{
if (!IN_DEV_SOURCE_ROUTE(in_dev))
{
Re: [PATCH V6 0/9] net/bonding: ADD IPoIB support for the bonding driver
> Roland, are you comfortable with the IB changes in patches 1 and 2? Yes, they look fine to me. Feel free to apply, with Acked-by: Roland Dreier <[EMAIL PROTECTED]> - R. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH: 2.6.13-15-SMP 3/3] network: concurrently runsoftirqnetwork code on SMP
On Tue, 25 Sep 2007 23:36:25 +0800 "john ye" <[EMAIL PROTECTED]> wrote: > Jamal, > > You pointed out a key point: it's NOT acceptable if massive packet > re-ordering couldn¡¯t be avoided. > I debugged function tcp_ofo_queue in net/ipv4/tcp_input.c & monitored > out_of_order_queue, found that re-ordering > becomes unacceptable with the softirq load grows. > > It's simple to avoid out-of-order packets by changing random dispatch into > dispatch based on source ip address. > e.g. cpu = iph->saddr % nr_cpus. while cpu is like a hash entry. > Considering that BS patch is mainly used on server with many incoming > connections, > dispatch by IP should balance CPU load well. > > The test is under way, it's not bad so far. > The queue spin_lock seems not cost much. > > Below is the bcpp beautified module code. Last time code mess is caused by > outlook express which killed tabs. > > Thanks. > > John Ye There is a standard hash called RSS, that many drivers support because it is used by other operating systems. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove broken netfilter binary sysctls from bridging code
On Tue, 25 Sep 2007 06:07:24 +0200 Patrick McHardy <[EMAIL PROTECTED]> wrote: > Stephen Hemminger wrote: > > On Mon, 24 Sep 2007 18:55:38 +0200 > > Patrick McHardy <[EMAIL PROTECTED]> wrote: > > > >>Eric W. Biederman wrote: > >> > >>>A really good fix would be to remove the binary side and then to > >>>modify brnf_sysctl_call_tables to allocate a temporary ctl_table > >>>and integer on the stack and only set ctl->data after we have > >>>normalized the written value. But since in practice nothing cares > >>>about the race a better fix probably isn't worth it. > >> > >> > >>I seem to be missing something, the entire brnf_sysctl_call_tables > >>thing looks purely cosmetic to me, wouldn't it be better to simply > >>remove it? > > > > > > I agree, removing seems like a better option. But probably need to > > go through a 3-6mo warning period, since sysctl's are technically > > an API. > > > I meant removing brnf_sysctl_call_tables function, not the sysctls > themselves, all it does is change values != 0 to 1. Or did you > actually mean that something in userspace might depend on reading > back the value 1 after writing a value != 0? I was going farther, because don't really see the value of having a sysctl for this. It seems better to just not load filters if they aren't going to be used. Having another enable/disable hook just adds needless complexity. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23-rc8-mm1 - drivers/net/ibm_newemac/mal - broken
On Tue, 25 Sep 2007 18:23:58 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote: > Hi Andrew, > > The drivers/net/ibm_newemac/mal seems to be broken, which stop with > build error (please cc netdev@vger.kernel.org on networking things) > CC drivers/net/ibm_newemac/mal.o > drivers/net/ibm_newemac/mal.c: In function ‘mal_schedule_poll’: > drivers/net/ibm_newemac/mal.c:238: error: too few arguments to function > ‘netif_rx_schedule_prep’ > drivers/net/ibm_newemac/mal.c:238: error: too few arguments to function > ‘netif_rx_schedule_prep’ > drivers/net/ibm_newemac/mal.c:238: error: too few arguments to function > ‘netif_rx_schedule_prep’ > drivers/net/ibm_newemac/mal.c:241: error: too few arguments to function > ‘__netif_rx_schedule’ > drivers/net/ibm_newemac/mal.c: In function ‘mal_poll_disable’: > drivers/net/ibm_newemac/mal.c:321: error: ‘__LINK_STATE_RX_SCHED’ undeclared > (first use in this function) > drivers/net/ibm_newemac/mal.c:321: error: (Each undeclared identifier is > reported only once > drivers/net/ibm_newemac/mal.c:321: error: for each function it appears in.) > drivers/net/ibm_newemac/mal.c: In function ‘mal_poll’: > drivers/net/ibm_newemac/mal.c:337: error: ‘struct net_device’ has no member > named ‘quota’ > drivers/net/ibm_newemac/mal.c:337: warning: type defaults to ‘int’ in > declaration of ‘_x’ > drivers/net/ibm_newemac/mal.c:337: error: ‘struct net_device’ has no member > named ‘quota’ > drivers/net/ibm_newemac/mal.c:375: error: too few arguments to function > ‘__netif_rx_complete’ > drivers/net/ibm_newemac/mal.c:390: warning: passing argument 2 of > ‘netif_rx_reschedule’ makes pointer from integer without a cast > drivers/net/ibm_newemac/mal.c:404: error: ‘struct net_device’ has no member > named ‘quota’ > drivers/net/ibm_newemac/mal.c: In function ‘mal_probe’: > drivers/net/ibm_newemac/mal.c:542: error: ‘struct net_device’ has no member > named ‘weight’ > drivers/net/ibm_newemac/mal.c:543: error: ‘struct net_device’ has no member > named ‘poll’ > drivers/net/ibm_newemac/mal.c: In function ‘mal_remove’: > drivers/net/ibm_newemac/mal.c:660: error: implicit declaration of function > ‘netif_poll_disable’ > make[3]: *** [drivers/net/ibm_newemac/mal.o] Error 1 > make[2]: *** [drivers/net/ibm_newemac] Error 2 > make[1]: *** [drivers/net] Error 2 > make: *** [drivers] Error 2 Yes, there's been a lot of breakage in netdev land: git-net-fix-macec.patch git-net-sky2-fixups.patch git-net-fix-wireless-kconfig.patch git-net-fix-spidernet-build.patch git-net-sctp-build-fix.patch spider_net_ethtool-keep-up-with-recent-netdev-stats-changes.patch pasemi_mac-build-fix-after-recent-netdev-stats.patch git-net-fix-pasemi_mac.patch make-mv643xx_ethc-build-again.patch but we're getting there. It looks like ibmn_newemac is more busted than most... - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sb1250-mac: Driver model & phylib update
On Tue, 25 Sep 2007 14:18:17 +0100 Ralf Baechle <[EMAIL PROTECTED]> wrote: > On Fri, Sep 21, 2007 at 12:44:09PM -0700, Andrew Morton wrote: > > > > A driver model and phylib update. > > > > akpm:/usr/src/25> diffstat patches/git-net.patch | tail -n 1 > > 1013 files changed, 187667 insertions(+), 23587 deletions(-) > > > > Sorry, but raising networking patches against Linus's crufty > > old mainline tree just isn't viable at present. > > Out of curiosity: > > [EMAIL PROTECTED] linux-queue]$ git diff $(git merge-base master > v2.6.23-rc8-mm1)..v2.6.23-rc8-mm1 | wc -cl > 1046669 31900996 > [EMAIL PROTECTED] linux-queue]$ git diff $(git merge-base master > v2.6.23-rc8-mm1)..v2.6.23-rc8-mm1 | diffstat | tail -1 > 6049 files changed, 573635 insertions(+), 207630 deletions(-) A few years ago I thought it might slow down soon. > [EMAIL PROTECTED] linux-queue]$ > > We're all a little too productive ;-) s/prod/destr/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove broken netfilter binary sysctls from bridging code
Stephen Hemminger wrote: On Tue, 25 Sep 2007 06:07:24 +0200 Patrick McHardy <[EMAIL PROTECTED]> wrote: I meant removing brnf_sysctl_call_tables function, not the sysctls themselves, all it does is change values != 0 to 1. Or did you actually mean that something in userspace might depend on reading back the value 1 after writing a value != 0? I was going farther, because don't really see the value of having a sysctl for this. It seems better to just not load filters if they aren't going to be used. Having another enable/disable hook just adds needless complexity. These sysctls control whether bridged packets will be handled by iptables and friends. The bridge netfilter code always handles bridged packets, and iptables might be loaded for different reasons. So I don't see how that would work. I think it should be specified in the ebtables ruleset, but the current netfilter infrastructure doesn't allow to do that cleanly. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
Patrick McHardy wrote:
> Urs Thuermann wrote:
>
>> YOSHIFUJI Hideaki / È£ÑÀ <[EMAIL PROTECTED]> writes:
>>
>>
>>
>>> I'm not a lawyer, but the following lines:
>>>
>>> | + * Alternatively, provided that this notice is retained in full, this
>>> ~~
>>> | + * software may be distributed under the terms of the GNU General
>>> | + * Public License ("GPL") version 2 as distributed in the 'COPYING'
>>> | + * file from the main directory of the linux kernel source.
>>>
>>> make this whole licence imcompatible with GPL.
>>>
>>
The module license is "Dual BSD/GPL" as many other code in the Linux
Kernel. So this should not be any problem.
>>> I do think you need to allow people to select GPLv2 only.
>>>
>>
The Linux Kernel is currently under GPLv2 and we just wanted to follow
Linus' mind and so we referenced the COPYING file which many other
source does as well. Indeed it was a hard thing to make our code
available under GPL (as creating and publishing open source software is
really no a usual thing for the Volkswagen rights department). So i
discussed with the rights department about several disclaimers inside
the current Kernel (especially the stuff that has been signed off by
companies like IBM, Motorola, etc.). In this process it turned out to be
the best to license the code under "Dual BSD/GPL" as it grants more
rights to the programmer (including ourselves) than a GPL only license.
I assume this was the intention from IBM, Motorola and all the others
also. Btw. inside the Kernel context it behaves exactly like GPL code
(like all the other dual license code).
So i really can't see any problem here. If so there would have been a
big discussion about the other "Dual BSD/GPL" code.
Best regards,
Oliver
ps. I hope, i found the right words right now, as i'm not very familiar
with English :)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Userspace network stack and netchannels.
Hi. I've released new version of the extremely small userspace netowork stack [1] implementation. Stack supports TCP and UDP over IP. It works on top of netchannels [2] or packet socket (returned back in this release). Supported features: * TCP/UDP sending and receiving. * Timestamp, window scaling, MSS TCP options. * PAWS. * Slow start and congestion control. * Socket-like interface. * Retransmit and fast retransmit support. * support for TCP listen state (only point-to-point mode, i.e. no new data channels are created, when new client is connected, instead state is changed according to protocol (TCP state is changed to ESTABLISHED). * support for the netchannels and packet socket interface. It was proven [3] that unetstack can be *much* faster than vanilla TCP stack (mainly because of heavily reduced number of syscalls, different congestion control algorithm and other features). This release includes number of bugs fixed (thanks to Salvatore Del Popolo for continuously kicking me), packet socket interface (enabled at compile time) and small documentation update (including example). Attached archive for intrested readers. Thank you. 1. Userspace network stack. http://tservice.net.ru/~s0mbre/old/?section=projects&item=unetstack 2. Netchannel subsystem. http://tservice.net.ru/~s0mbre/old/?section=projects&item=netchannel 3. Gigabit send/recv benchmark for netchannels and sockets using small packets. http://tservice.net.ru/~s0mbre/blog/devel/networking/2006_10_26.html http://tservice.net.ru/~s0mbre/blog/devel/networking/2006_12_21.html -- Evgeniy Polyakov unetstack-2007_09_25.tar.gz Description: application/tar-gz
Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
Oliver Hartkopp wrote: I do think you need to allow people to select GPLv2 only. >>> > The Linux Kernel is currently under GPLv2 and we just wanted to follow > Linus' mind and so we referenced the COPYING file which many other > source does as well. Indeed it was a hard thing to make our code > available under GPL (as creating and publishing open source software is > really no a usual thing for the Volkswagen rights department). So i > discussed with the rights department about several disclaimers inside > the current Kernel (especially the stuff that has been signed off by > companies like IBM, Motorola, etc.). In this process it turned out to be > the best to license the code under "Dual BSD/GPL" as it grants more > rights to the programmer (including ourselves) than a GPL only license. > I assume this was the intention from IBM, Motorola and all the others > also. Btw. inside the Kernel context it behaves exactly like GPL code > (like all the other dual license code). > > So i really can't see any problem here. If so there would have been a > big discussion about the other "Dual BSD/GPL" code. Yoshifuji's point was that the license seems to contradict itself, it says you may choose GPL, but have to retain BSD. And that is not about Dual BSD/GPL but about the specific wording. /me runs and refrains from the discussion as promised :) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
Patrick McHardy wrote: > > Yoshifuji's point was that the license seems to contradict itself, > it says you may choose GPL, but have to retain BSD. And that is > not about Dual BSD/GPL but about the specific wording. > Got it (finally)! Trying to specify the GPL Version (and the reference to the COPYING file) i just overlooked the second part "*/*/in which case the provisions of the GPL apply INSTEAD OF those given above."/*/* of the original sentence. Sorry. Was no* malice aforethought :)* Of course we'll fix this to have the same wording like e.g. in arch/i386/crypto/aes.c . Thanks to Yoshfuji for catching this and to Patrick for making it clear to me!* Best regards, Oliver * - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Userspace network stack and netchannels.
Evgeniy, On 9/25/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > I've released new version of the extremely small > userspace netowork stack [1] implementation. > > 1. Userspace network stack. > http://tservice.net.ru/~s0mbre/old/?section=projects&item=unetstack > > 2. Netchannel subsystem. > http://tservice.net.ru/~s0mbre/old/?section=projects&item=netchannel > > 3. Gigabit send/recv benchmark for netchannels and sockets using small > packets. > http://tservice.net.ru/~s0mbre/blog/devel/networking/2006_10_26.html > http://tservice.net.ru/~s0mbre/blog/devel/networking/2006_12_21.html > Very interesting. Are there any details of your benchmarking available, namely, how it was done? Have you some comparison profiling data (oprofile) to figure out where the advantages are coming from? -- Sincerely, Robert Iakobashvili, coroberti %x40 gmail %x2e com ... http://curl-loader.sourceforge.net A web testing and traffic generation tool. -- Sincerely, Robert Iakobashvili, coroberti %x40 gmail %x2e com ... http://curl-loader.sourceforge.net A web testing and traffic generation tool. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Userspace network stack and netchannels.
On Tue, 25 Sep 2007 22:00:48 +0400 Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > Hi. > > I've released new version of the extremely small > userspace netowork stack [1] implementation. > Stack supports TCP and UDP over IP. > It works on top of netchannels [2] or packet socket > (returned back in this release). > > Supported features: > * TCP/UDP sending and receiving. > * Timestamp, window scaling, MSS TCP options. > * PAWS. > * Slow start and congestion control. > * Socket-like interface. > * Retransmit and fast retransmit support. > * support for TCP listen state (only point-to-point mode, > i.e. no new data channels are created, when new client is > connected, instead state is changed according to protocol > (TCP state is changed to ESTABLISHED). > * support for the netchannels and packet socket interface. > > It was proven [3] that unetstack can be *much* faster than vanilla TCP > stack (mainly because of heavily reduced number of syscalls, different > congestion control algorithm and other features). I am glad to see a more complete implementation for comparison, but by changing several variables at once it makes it hard to evaluate whether the improvement comes from user space TCP or the other changes. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[git patches] additional net driver fixes
These two wireless fixes are IN ADDITION to the previously submitted
fixes. Same linear history. In other words, if you pull
"upstream-linus", you will get both the changes below, _and_ the changes
I submitted yesterday. If you have already pulled yesterday's fixes,
then you will only receive the changesets below.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
fs/compat_ioctl.c |2 +
net/ieee80211/softmac/ieee80211softmac_assoc.c |2 -
net/ieee80211/softmac/ieee80211softmac_wx.c| 54 +---
7 files changed, 61 insertions(+), 52 deletions(-)
Jean Tourrilhes (1):
WE : Add missing auth compat-ioctl
Larry Finger (1):
softmac: Fix inability to associate with WEP networks
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index 5a5b711..37310b0 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -3190,6 +3190,8 @@ COMPATIBLE_IOCTL(SIOCSIWRETRY)
COMPATIBLE_IOCTL(SIOCGIWRETRY)
COMPATIBLE_IOCTL(SIOCSIWPOWER)
COMPATIBLE_IOCTL(SIOCGIWPOWER)
+COMPATIBLE_IOCTL(SIOCSIWAUTH)
+COMPATIBLE_IOCTL(SIOCGIWAUTH)
/* hiddev */
COMPATIBLE_IOCTL(HIDIOCGVERSION)
COMPATIBLE_IOCTL(HIDIOCAPPLICATION)
diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c
b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index afb6c66..e475f2e 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -273,8 +273,6 @@ ieee80211softmac_assoc_work(struct work_struct *work)
ieee80211softmac_notify(mac->dev,
IEEE80211SOFTMAC_EVENT_SCAN_FINISHED, ieee80211softmac_assoc_notify_scan, NULL);
if (ieee80211softmac_start_scan(mac)) {
dprintk(KERN_INFO PFX "Associate: failed to
initiate scan. Is device up?\n");
- mac->associnfo.associating = 0;
- mac->associnfo.associated = 0;
}
goto out;
} else {
diff --git a/net/ieee80211/softmac/ieee80211softmac_wx.c
b/net/ieee80211/softmac/ieee80211softmac_wx.c
index d054e92..442b987 100644
--- a/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ b/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -70,44 +70,30 @@ ieee80211softmac_wx_set_essid(struct net_device *net_dev,
char *extra)
{
struct ieee80211softmac_device *sm = ieee80211_priv(net_dev);
- struct ieee80211softmac_network *n;
struct ieee80211softmac_auth_queue_item *authptr;
int length = 0;
check_assoc_again:
mutex_lock(&sm->associnfo.mutex);
- /* Check if we're already associating to this or another network
-* If it's another network, cancel and start over with our new network
-* If it's our network, ignore the change, we're already doing it!
-*/
if((sm->associnfo.associating || sm->associnfo.associated) &&
(data->essid.flags && data->essid.length)) {
- /* Get the associating network */
- n = ieee80211softmac_get_network_by_bssid(sm,
sm->associnfo.bssid);
- if(n && n->essid.len == data->essid.length &&
- !memcmp(n->essid.data, extra, n->essid.len)) {
- dprintk(KERN_INFO PFX "Already associating or
associated to "MAC_FMT"\n",
- MAC_ARG(sm->associnfo.bssid));
- goto out;
- } else {
- dprintk(KERN_INFO PFX "Canceling existing associate
request!\n");
- /* Cancel assoc work */
- cancel_delayed_work(&sm->associnfo.work);
- /* We don't have to do this, but it's a little cleaner
*/
- list_for_each_entry(authptr, &sm->auth_queue, list)
- cancel_delayed_work(&authptr->work);
- sm->associnfo.bssvalid = 0;
- sm->associnfo.bssfixed = 0;
- sm->associnfo.associating = 0;
- sm->associnfo.associated = 0;
- /* We must unlock to avoid deadlocks with the assoc
workqueue
-* on the associnfo.mutex */
- mutex_unlock(&sm->associnfo.mutex);
- flush_scheduled_work();
- /* Avoid race! Check assoc status again. Maybe someone
started an
-* association while we flushed. */
- goto check_assoc_again;
- }
+ dprintk(KERN_INFO PFX "Canceling existing associate
request!\n");
+ /* Cancel assoc work */
+ cancel_delayed_work(&sm->associnfo.work);
+ /* We don't have to do this, but it's a little cleaner */
+ list_
Re: [DOC] Net batching driver howto
On Mon, 24 Sep 2007 18:54:19 -0400 jamal wrote: > I have updated the driver howto to match the patches i posted yesterday. > attached. Thanks for sending this. This is an early draft, right? I'll fix some typos etc. in it (patch attached) and add some whitespace. Please see RD: in the patch for more questions/comments. IMO it needs some changes to eliminate words like "we", "you", and "your" (words that personify code). Those words are OK when talking about yourself. --- ~Randy Phaedrus says that Quality is about caring. batch-driver-howto.txt | 116 +-- 1 file changed, 63 insertions(+), 53 deletions(-) diff -Naurp tmp/batch-driver-howto.txt~fix1 tmp/batch-driver-howto.txt --- tmp/batch-driver-howto.txt~fix1 2007-09-25 12:44:10.0 -0700 +++ tmp/batch-driver-howto.txt 2007-09-25 13:14:27.0 -0700 @@ -1,13 +1,13 @@ -Heres the begining of a howto for driver authors. +Here's the beginning of a howto for driver authors. The intended audience for this howto is people already familiar with netdevices. -1.0 Netdevice Pre-requisites +1.0 Netdevice Prerequisites -- -For hardware based netdevices, you must have at least hardware that -is capable of doing DMA with many descriptors; i.e having hardware +For hardware-based netdevices, you must have at least hardware that +is capable of doing DMA with many descriptors; i.e., having hardware with a queue length of 3 (as in some fscked ethernet hardware) is not very useful in this case. @@ -15,33 +15,36 @@ not very useful in this case. --- There are 3 new methods and one new variable introduced. These are: -1)dev->hard_prep_xmit() -2)dev->hard_end_xmit() -3)dev->hard_batch_xmit() -4)dev->xmit_win +1) dev->hard_prep_xmit() +2) dev->hard_end_xmit() +3) dev->hard_batch_xmit() +4) dev->xmit_win 2.1 Using Core driver changes - -To provide context, lets look at a typical driver abstraction +To provide context, let's look at a typical driver abstraction for dev->hard_start_xmit(). It has 4 parts: -a) packet formating (example vlan, mss, descriptor counting etc) -b) chip specific formatting +a) packet formatting (example: vlan, mss, descriptor counting, etc.) +b) chip-specific formatting c) enqueueing the packet on a DMA ring d) IO operations to complete packet transmit, tell DMA engine to chew -on, tx completion interupts etc +on, tx completion interrupts, etc. [For code cleanliness/readability sake, regardless of this work, one should break the dev->hard_start_xmit() into those 4 functions anyways]. + A driver which has all 4 parts and needing to support batching is advised to split its dev->hard_start_xmit() in the following manner: -1)use its dev->hard_prep_xmit() method to achieve #a -2)use its dev->hard_end_xmit() method to achieve #d -3)#b and #c can stay in ->hard_start_xmit() (or whichever way you + +1) use its dev->hard_prep_xmit() method to achieve #a +2) use its dev->hard_end_xmit() method to achieve #d +3) #b and #c can stay in ->hard_start_xmit() (or whichever way you want to do this) + Note: There are drivers which may need not support any of the two -methods (example the tun driver i patched) so the two methods are +methods (for example, the tun driver I patched), so the two methods are essentially optional. 2.1.1 Theory of operation @@ -49,7 +52,7 @@ essentially optional. The core will first do the packet formatting by invoking your supplied dev->hard_prep_xmit() method. It will then pass you the packet -via your dev->hard_start_xmit() method for as many as packets you +via your dev->hard_start_xmit() method for as many packets as you have advertised (via dev->xmit_win) you can consume. Lastly it will invoke your dev->hard_end_xmit() when it completes passing you all the packets queued for you. @@ -58,16 +61,16 @@ packets queued for you. 2.1.1.1 Locking rules - -dev->hard_prep_xmit() is invoked without holding any -tx lock but the rest are under TX_LOCK(). So you have to ensure that -whatever you put it dev->hard_prep_xmit() doesnt require locking. +dev->hard_prep_xmit() is invoked without holding any tx lock +but the rest are under TX_LOCK(). So you have to ensure that +whatever you put it dev->hard_prep_xmit() doesn't require locking. 2.1.1.2 The slippery LLTX - LLTX drivers present a challenge in that we have to introduce a deviation from the norm and require the ->hard_batch_xmit() method. An LLTX -driver presents us with ->hard_batch_xmit() to which we pass it a list +driver presents us with ->hard_batch_xmit() to which we pass in a list of packets in a dev->blist skb queue. It is then the responsibility of the ->hard_batch_xmit() to exercise steps #b and #c for all packets passed in the dev->blist. @@ -80,11 +83,14 @@ dev->hard_prep_xmit() and dev->hard_end_ dev->xmit_win variable is set b
Re: [PATCH 2/7] CAN: Add PF_CAN core module
Stephen Hemminger <[EMAIL PROTECTED]> writes: > Then please make all exported symbols marked EXPORT_SYMBOL_GPL to make > sure that the other CAN protocol can not reuse your infrastructure. We don't want to force other CAN protocol implementations to be GPL also. AFAIR from discussions on LKML, it was mostly agreed upon that this decision is up to the authors of code. urs - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] CAN: Add PF_CAN core module
On 25 Sep 2007 23:00:15 +0200 Urs Thuermann <[EMAIL PROTECTED]> wrote: > Stephen Hemminger <[EMAIL PROTECTED]> writes: > > > Then please make all exported symbols marked EXPORT_SYMBOL_GPL to > > make sure that the other CAN protocol can not reuse your > > infrastructure. > > We don't want to force other CAN protocol implementations to be GPL > also. AFAIR from discussions on LKML, it was mostly agreed upon that > this decision is up to the authors of code. > > urs I just don't want proprietary drivers extensions in linux kernel. EXPORT_SYMBOL has no meaning in other OS environments. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
my plans...
I just got back from some travelling this past weekend, so what I'm going to do today is: 1) Rebase net-2.6.24, that's what I'm doing right now. I'll be combining bug fixes for feature patches as much as possible, so this might take most if not all of this afternoon. 2) After the rebase is done I'll go through the patches in my backlog for net-2.6.24 which have accumulated. Thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] CAN: Add PF_CAN core module
From: Urs Thuermann <[EMAIL PROTECTED]> Date: 25 Sep 2007 23:00:15 +0200 > Stephen Hemminger <[EMAIL PROTECTED]> writes: > > > Then please make all exported symbols marked EXPORT_SYMBOL_GPL to make > > sure that the other CAN protocol can not reuse your infrastructure. > > We don't want to force other CAN protocol implementations to be GPL > also. AFAIR from discussions on LKML, it was mostly agreed upon that > this decision is up to the authors of code. To a certain extent, yes. However, the core issue is whether anyone who uses the symbol is creating a derivative work. If it is pretty clear that this is the case, you really should mark the exported symbols GPL. In my opinion, in this case it is pretty clear that any use of these new symbols would be a derivative work and therefore they all should be marked GPL. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] [NET_SCHED] explict hold dev tx lock
On Tue, 2007-25-09 at 08:24 -0700, Stephen Hemminger wrote: > The transmit code path is locked as a code region, rather than just object > locking > on the transmit queue or other fine grained object. This leads to moderately > long > lock hold times when multiple qdisc's and classification is being done. It will be pretty tricky to optimize that path given the dependencies between the queues, classifiers, and actions in enqueues; schedulers in dequeues as well as their config/queries from user space which could happen concurently on all "N" CPUs. The txlock optimization i added in patch1 intends to let go of the queue lock when we enter the dequeue region sooner to reduce the contention. A further optimization i made was to reduce the time it takes to hold the tx lock at the driver by moving gunk that doesnt need lock-holding into the new method dev->hard_end_xmit() (refer to patch #2) > If we went to finer grain locking it would also mean changes to all network > devices using the new locking model. My assumption is that we would use > something like the features flag to do the transition for backward > compatibility. > Take this as a purely "what if" or "it would be nice if" kind of suggestion > not a requirement or some grand plan. Ok, hopefully someone would demonstrate how to achieve it; seems a hard thing to achieve. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH: 2.6.13-15-SMP 3/3] network: concurrently runsoftirqnetwork code on SMP
On Tue, 2007-25-09 at 09:03 -0700, Stephen Hemminger wrote: > There is a standard hash called RSS, that many drivers support because it is > used by other operating systems. I think any stateless/simple thing will do (something along the lines what 802.1ad does for trunk, a 5 classical five tuple etc). Having solved the reordering problem in such a stateless way introduces a loadbalancing setback; you may end sending all your packets to one cpu (a problem Mr Ye didnt have when he was re-orderding ;->). cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DOC] Net batching driver howto
On Tue, 2007-25-09 at 13:16 -0700, Randy Dunlap wrote: > On Mon, 24 Sep 2007 18:54:19 -0400 jamal wrote: > > > I have updated the driver howto to match the patches i posted yesterday. > > attached. > > Thanks for sending this. Thank you for reading it Randy. > This is an early draft, right? Its a third revision - but you could call it early. When it is done, i will probably put a pointer to it in some patch. > I'll fix some typos etc. in it (patch attached) and add some whitespace. > Please see RD: in the patch for more questions/comments. Thanks, will do and changes will show up in the next update. > IMO it needs some changes to eliminate words like "we", "you", > and "your" (words that personify code). Those words are OK > when talking about yourself. The narrative intent is supposed to be i (or someone doing the description) sitting there with a pen and paper and maybe a laptop and walking through the details with someone who needs to understand those details. If you think it is important to make it formal, then by all means be my guest. Again, thanks for taking the time. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] [NET_SCHED] explict hold dev tx lock
On Tue, 2007-25-09 at 18:15 -0400, jamal wrote: > A further optimization i made was to reduce the time it takes to hold > the tx lock at the driver by moving gunk that doesnt need lock-holding > into the new method dev->hard_end_xmit() (refer to patch #2) Sorry, that should have read dev->hard_prep_xmit() cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mv643xx_eth: duplicate methods in initializer
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/net/mv643xx_eth.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index 6a117e9..456d1e1 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -2768,8 +2768,6 @@ static const struct ethtool_ops mv643xx_ethtool_ops = {
.get_stats_count= mv643xx_get_stats_count,
.get_ethtool_stats = mv643xx_get_ethtool_stats,
.get_strings= mv643xx_get_strings,
- .get_stats_count= mv643xx_get_stats_count,
- .get_ethtool_stats = mv643xx_get_ethtool_stats,
.nway_reset = mv643xx_eth_nway_restart,
};
--
1.5.3.GIT
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [net-2.6.24][patch 2/2] Dynamically allocate the loopback device
From: [EMAIL PROTECTED] (Eric W. Biederman) Date: Mon, 17 Sep 2007 20:44:14 -0600 > David Miller <[EMAIL PROTECTED]> writes: > > > From: "Peter Waskiewicz" <[EMAIL PROTECTED]> > > Date: Mon, 17 Sep 2007 12:12:24 -0700 > > > >> This would be a good opportunity to remove the single-allocated queue > >> struct > >> in netdevice (at the bottom) that we had to put in to accomodate the static > >> loopback. Now we can set it back to a zero element list, and have > >> alloc_netdev_mq() just allocate the number of queues requested, not > >> num_queues - 1. > >> > >> I'll put a patch together based on this patchset. > > > > Thanks Peter. > > > > I'll also let this sit so that Eric can provide any feedback > > he wants and also figure out how he will use this for the > > namespace stuff. > > Acked-by: "Eric W. Biederman" <[EMAIL PROTECTED]> > Not that it doesn't already have my signed off by. I've put these patches into the just-rebased net-2.6.24 tree. I made a minor modification to the second patch, the out_free_netdev: code in loopback_init() ended like this: out_free_netdev: free_netdev(dev); goto out; return err; }; I got rid of the spurious return statement and the trailing semi-colon after the function closing brace. Thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] move hardware header functions out of netdevice
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Fri, 24 Aug 2007 13:43:10 -0700 > The follow patches series starts the process of moving function > pointers out of network device structure. This saves space and > separates code from data. > > The first step is moving the functions dealing with hardware > headers. > > Patches are against current net-2.6.24 tree. Basic functional > testing on ethernet part, not on all the other protocols affected. Stephen, can you respin these against net-2.6.24 and resubmit? Thanks! - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][NET_SCHED] explict hold dev tx lock
From: jamal <[EMAIL PROTECTED]> Date: Wed, 19 Sep 2007 22:43:03 -0400 > [NET_SCHED] explict hold dev tx lock > > For N cpus, with full throttle traffic on all N CPUs, funneling traffic > to the same ethernet device, the devices queue lock is contended by all > N CPUs constantly. The TX lock is only contended by a max of 2 CPUS. > In the current mode of operation, after all the work of entering the > dequeue region, we may endup aborting the path if we are unable to get > the tx lock and go back to contend for the queue lock. As N goes up, > this gets worse. > > The changes in this patch result in a small increase in performance > with a 4CPU (2xdual-core) with no irq binding. Both e1000 and tg3 > showed similar behavior; > > Signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]> I've applied this to net-2.6.24, although I want to study more deeply the implications of this change myself at some point :) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - net-2.6.24 0/2] Introduce and use print_ip and print_ipv6
From: Joe Perches <[EMAIL PROTECTED]> Date: Wed, 19 Sep 2007 23:53:31 -0700 > In the same vein as print_mac, the implementations > introduce declaration macros: I'm going to hold on this for now, there is no universal agreement that this is something we want to do and I'd like to take care of getting the more certain stuff into net-2.6.24 before "iffy" bits like this one. Thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH: 2.6.13-15-SMP 3/3] network: concurrentlyrunsoftirqnetwork code on SMP
Jamal & Stephen, I found BSS-hash paper you mentioned and have browsed it briefly. The issue "may end sending all your packets to one cpu" might be dealt with by cpu hash (srcip + dstip) % nr_cpus, plus checking cpu balance periodically, shift cpu by an extra seed value? Any way, the cpu hash code must not be too expensive because every incoming packet hits the path. We are going to do further study on this BSS thing. __do_IRQ has a tendency to collect same IRQ on different CPUs into one CPU when NIC is busy(by IRQ_PENDING & IRQ_INPROGRESS control skill). so, dispatch the load to SMP here may be good thing(?). Thanks. John Ye - Original Message - From: "jamal" <[EMAIL PROTECTED]> To: "Stephen Hemminger" <[EMAIL PROTECTED]> Cc: "john ye" <[EMAIL PROTECTED]>; "David Miller" <[EMAIL PROTECTED]>; ; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, September 26, 2007 6:22 AM Subject: Re: [PATCH: 2.6.13-15-SMP 3/3] network: concurrentlyrunsoftirqnetwork code on SMP > On Tue, 2007-25-09 at 09:03 -0700, Stephen Hemminger wrote: > > > There is a standard hash called RSS, that many drivers support because it is > > used by other operating systems. > > I think any stateless/simple thing will do (something along the lines > what 802.1ad does for trunk, a 5 classical five tuple etc). > > Having solved the reordering problem in such a stateless way introduces > a loadbalancing setback; you may end sending all your packets to one cpu > (a problem Mr Ye didnt have when he was re-orderding ;->). > > cheers, > jamal > > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/1] revert "8139too: clean up I/O remapping"
From: Jeff Garzik <[EMAIL PROTECTED]> Date: Thu, 20 Sep 2007 16:58:43 -0400 > [EMAIL PROTECTED] wrote: > > From: Andrew Morton <[EMAIL PROTECTED]> > > > > Revert git-netdev-all's 9ee6b32a47b9abc565466a9c3b127a5246b452e5. Michal > > was > > getting oopses. > > > > Cc: Michal Piotrowski <[EMAIL PROTECTED]> > > Cc: Jeff Garzik <[EMAIL PROTECTED]> > > Cc: David S. Miller" <[EMAIL PROTECTED]> > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > --- > > > > drivers/net/8139too.c | 50 +++- > > 1 file changed, 29 insertions(+), 21 deletions(-) > > ACK -- DaveM, please remove or revert this patch. > I've reverted this patch during the net-2.6.24 rebase I'm working on today. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull 'iwlwifi' branch of wireless-2.6
From: "John W. Linville" <[EMAIL PROTECTED]> Date: Thu, 20 Sep 2007 21:34:03 -0400 > On Fri, Sep 21, 2007 at 09:20:30AM +0800, Zhu Yi wrote: > > On Wed, 2007-09-19 at 11:13 +0100, Christoph Hellwig wrote: > > > it really needs to be moved into a directory of it's own. > > > > It used to be... John? > > Fine by me -- I guess I misinterpreted the some other statements to > make me think we wanted as flat a directory structure as possible. I've taken care of this during the net-2.6.24 rebase I'm working on today. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] note that NETIF_F_LLTX is deprecated
From: Herbert Xu <[EMAIL PROTECTED]> Date: Sat, 22 Sep 2007 08:57:10 +0800 > On Fri, Sep 21, 2007 at 04:59:54PM +0200, Christian Borntraeger wrote: > > > > I suggest to document that LLTX is deprecated. > > > > Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]> > > This looks good to me. To me too, applied to net-2.6.24, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull 'fixes-davem' branch of wireless-2.6 (for 2.6.23)
From: "John W. Linville" <[EMAIL PROTECTED]> Date: Sat, 22 Sep 2007 11:41:42 -0400 > These are a few more minor fixes that I would like to have in 2.6.23 if > at all possible. I've pulled these into my net-2.6 tree and will push to Linus, thanks! - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Zero-length write() does not generate a datagram on connected socket
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> The bug http://bugzilla.kernel.org/show_bug.cgi?id=5731
> describes an issue where write() can't be used to generate a zero-length
> datagram (but send, and sendto do work).
>
> I think the following is needed:
>
> --- a/net/socket.c 2007-08-20 09:54:28.0 -0700
> +++ b/net/socket.c 2007-09-24 15:31:25.0 -0700
> @@ -777,8 +777,11 @@ static ssize_t sock_aio_write(struct kio
>if (pos != 0)
>return -ESPIPE;
>
> - if (iocb->ki_left == 0) /* Match SYS5 behaviour */
> - return 0;
> + if (unlikely(iocb->ki_left == 0)) {
> + struct socket *sock = iocb->ki_filp->private_data;
> + if (sock->type == SOCK_STREAM)
> + return 0;
> + }
I'm not sure whether all STREAM protocols treat zero-length
sends as no-ops. What about SCTP?
Put it another way, do we really need to keep the short-circuit
for SOCK_STREAM?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - net-2.6.24 0/2] Introduce and use print_ip and print_ipv6
On Tue, 2007-09-25 at 19:29 -0700, David Miller wrote: > I'm going to hold on this for now, there is no universal > agreement that this is something we want to do and I'd > like to take care of getting the more certain stuff into > net-2.6.24 before "iffy" bits like this one. Here's an argument for inclusion: defconfig without patches: $ size vmlinux textdata bss dec hex filename 4738370 518986 622592 5879948 59b88c vmlinux defconfig with patches: $ size vmlinux textdata bss dec hex filename 4735238 518986 622592 5876816 59ac50 vmlinux cheers, Joe - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - net-2.6.24 0/2] Introduce and use print_ip and print_ipv6
From: Joe Perches <[EMAIL PROTECTED]> Date: Tue, 25 Sep 2007 21:36:38 -0700 > On Tue, 2007-09-25 at 19:29 -0700, David Miller wrote: > > I'm going to hold on this for now, there is no universal > > agreement that this is something we want to do and I'd > > like to take care of getting the more certain stuff into > > net-2.6.24 before "iffy" bits like this one. > > Here's an argument for inclusion: > > defconfig without patches: Sure, but this ignores certain things that text/data/bss size don't show you. For one thing, stack frames might now be larger in the functions where the new variables get added, even if they aren't used to print out the debugging message. And that could have negative performance implications. Nothing is every black and white, everything is gray :-) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - net-2.6.24 0/2] Introduce and use print_ip and print_ipv6
David Miller wrote: From: Joe Perches <[EMAIL PROTECTED]> Date: Tue, 25 Sep 2007 21:36:38 -0700 On Tue, 2007-09-25 at 19:29 -0700, David Miller wrote: I'm going to hold on this for now, there is no universal agreement that this is something we want to do and I'd like to take care of getting the more certain stuff into net-2.6.24 before "iffy" bits like this one. Here's an argument for inclusion: defconfig without patches: Sure, but this ignores certain things that text/data/bss size don't show you. size(1) output also ignores the merge noise this creates, and IMO we've got a lot of that already... Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Zero-length write() does not generate a datagram on connected socket
On Wed, 26 Sep 2007 11:18:39 +0800
Herbert Xu <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> > The bug http://bugzilla.kernel.org/show_bug.cgi?id=5731
> > describes an issue where write() can't be used to generate a zero-length
> > datagram (but send, and sendto do work).
> >
> > I think the following is needed:
> >
> > --- a/net/socket.c 2007-08-20 09:54:28.0 -0700
> > +++ b/net/socket.c 2007-09-24 15:31:25.0 -0700
> > @@ -777,8 +777,11 @@ static ssize_t sock_aio_write(struct kio
> >if (pos != 0)
> >return -ESPIPE;
> >
> > - if (iocb->ki_left == 0) /* Match SYS5 behaviour */
> > - return 0;
> > + if (unlikely(iocb->ki_left == 0)) {
> > + struct socket *sock = iocb->ki_filp->private_data;
> > + if (sock->type == SOCK_STREAM)
> > + return 0;
> > + }
>
> I'm not sure whether all STREAM protocols treat zero-length
> sends as no-ops. What about SCTP?
>
> Put it another way, do we really need to keep the short-circuit
> for SOCK_STREAM?
>
> Cheers,
Stream is defined as sequence of bytes. So short circuit makes sense
If the application wants message boundaries it needs to use SOCK_SEQPACKET.
I was paranoid about possible breakage in TCP or SCTP. But since
send(s, buf, 0, 0) already filters through, I guess it doesn't matter.
--
Stephen Hemminger <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull 'upstream-davem' branch of wireless-2.6 (for 2.6.24)
From: "John W. Linville" <[EMAIL PROTECTED]> Date: Sat, 22 Sep 2007 15:54:57 -0400 > The individual patches are available here: > > > http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-davem/ I sucked these into my net-2.6.24 tree, thanks John. It may look slightly different because I applied the iwlwifi CFLAGS Makefile patch directly from Intel and I did the iwlwifi directory source move on my own. Thanks! - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] [TCP]: Re-place highest_sack check to a more robust position
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Mon, 24 Sep 2007 12:04:06 +0300 > I previously added checking to position that is rather poor as > state has already been adjusted quite a bit. Re-placing it above > all state changes should be more robust though the return should > never ever get executed regardless of its place :-). > > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> Applied to net-2.6.24, thanks Ilpo. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/3] [TCP]: Reordered ACK's (old) SACKs not included to discarded MIB
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Mon, 24 Sep 2007 12:04:07 +0300 > In case of ACK reordering, the SACK block might be valid in it's > time but is already obsoleted since we've received another kind > of confirmation about arrival of the segments through snd_una > advancement of an earlier packet. > > I didn't bother to build distinguishing of valid and invalid > SACK blocks but simply made reordered SACK blocks that are too > old always not counted regardless of their "real" validity which > could be determined by using the ack field of the reordered > packet (won't be significant IMHO). > > DSACKs can very well be considered useful even in this situation, > so won't do any of this for them. > > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> This looks fine to me, applied. If the skipped case is interesting we can add another MIB stat for it :-) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/3] [TCP] MIB: Count FRTO's successfully detected spurious RTOs
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Mon, 24 Sep 2007 12:04:08 +0300 > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> This also looks fine, applied, thanks! - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SCTP PULL Request]: Bug fixes for 2.6.23
From: Vlad Yasevich <[EMAIL PROTECTED]> Date: Mon, 24 Sep 2007 16:59:25 -0400 > Can you please pull the following changes since commit > a41d3015c11a4e864b95cb57f579f2d8f40cd41b: I had to apply this by hand because: > David S. Miller (1): > Revert "PCI: disable MSI by default on systems with Serverworks > HT1000 chips" You did this work on a very old tree of mine that I redid at one point. This MSI changeset I yanked out of my net-2.6 tree during a rebase, so if I pull I get the thing back which I definitely don't want :-) Just to let you know what's happening and why I couldn't pull directly from your tree into mine. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
net-2.6.24 rebased...
Ok the rebase is complete and I integrated all of the "easy" stuff in my backlog. In the usual spot: kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git John, one patch didn't go in cleanly after I removed the Z1211 driver. I put it here for your consideration so it doesn't get lost: http://vger.kernel.org/~davem/0433-Z1211-Fix-TX-status-reports.patch What probably needs to happen is some other changes that were in z1211 need to go into the non-mac80211 driver and then this patch applies correctly. I tried the simple thing to rename the directory in the patch and that didn't work, obviously :-) Jeff, if you have any pending driver bits please toss them my way as most of my backlog is clear now. Andrew, I applied a good chunk of the driver build fixes you had accumulated. I think I missed one or two, so please check that out and send my way the ones that I missed. Thanks! - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 33/43] lguest: Net driver using virtio
The network driver uses two virtqueues: one for input packets and one
for output packets. This has nice locking properties (ie. we don't do
any for recv vs send).
TODO:
1) Big packets.
2) Multi-client devices (maybe separate driver?).
3) Resolve freeing of old xmit skbs (Christian Borntraeger)
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Cc: Christian Borntraeger <[EMAIL PROTECTED]>
Cc: Herbert Xu <[EMAIL PROTECTED]>
Cc: netdev@vger.kernel.org
---
drivers/net/Kconfig|6
drivers/net/Makefile |2
drivers/net/virtio_net.c | 438
include/linux/virtio_net.h | 36 +++
4 files changed, 481 insertions(+), 1 deletion(-)
===
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2998,4 +2998,10 @@ config NET_POLL_CONTROLLER
config NET_POLL_CONTROLLER
def_bool NETPOLL
+config VIRTIO_NET
+ tristate "Virtio network driver (EXPERIMENTAL)"
+ depends on EXPERIMENTAL && VIRTIO
+ ---help---
+ This is the virtual network driver for lguest. Say Y or M.
+
endif # NETDEVICES
===
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -38,7 +38,7 @@ obj-$(CONFIG_SUNVNET) += sunvnet.o
obj-$(CONFIG_MACE) += mace.o
obj-$(CONFIG_BMAC) += bmac.o
-
+obj-$(CONFIG_VIRTIO_NET) += virtio_net.o
obj-$(CONFIG_DGRS) += dgrs.o
obj-$(CONFIG_VORTEX) += 3c59x.o
obj-$(CONFIG_TYPHOON) += typhoon.o
===
--- /dev/null
+++ b/drivers/net/virtio_net.c
@@ -0,0 +1,438 @@
+/* A simple network driver using virtio.
+ *
+ * Copyright 2007 Rusty Russell <[EMAIL PROTECTED]> IBM Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+//#define DEBUG
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* FIXME: MTU in config. */
+#define MAX_PACKET_LEN (ETH_HLEN+ETH_DATA_LEN)
+
+struct virtnet_info
+{
+ struct virtio_device *vdev;
+ struct virtqueue *rvq, *svq;
+ struct net_device *dev;
+
+ /* Number of input buffers, and max we've ever had. */
+ unsigned int num, max;
+
+ /* Receive & send queues. */
+ struct sk_buff_head recv;
+ struct sk_buff_head send;
+};
+
+static inline struct virtio_net_hdr *skb_vnet_hdr(struct sk_buff *skb)
+{
+ return (struct virtio_net_hdr *)skb->cb;
+}
+
+static inline void vnet_hdr_to_sg(struct scatterlist *sg, struct sk_buff *skb)
+{
+ sg_init_one(sg, skb_vnet_hdr(skb), sizeof(struct virtio_net_hdr));
+}
+
+static bool skb_xmit_done(struct virtqueue *rvq)
+{
+ struct virtnet_info *vi = rvq->vdev->priv;
+
+ /* In case we were waiting for output buffers. */
+ netif_wake_queue(vi->dev);
+ return true;
+}
+
+static void receive_skb(struct net_device *dev, struct sk_buff *skb,
+ unsigned len)
+{
+ struct virtio_net_hdr *hdr = skb_vnet_hdr(skb);
+
+ if (unlikely(len < sizeof(struct virtio_net_hdr) + ETH_HLEN)) {
+ pr_debug("%s: short packet %i\n", dev->name, len);
+ dev->stats.rx_length_errors++;
+ goto drop;
+ }
+ len -= sizeof(struct virtio_net_hdr);
+ BUG_ON(len > MAX_PACKET_LEN);
+
+ skb_trim(skb, len);
+ skb->protocol = eth_type_trans(skb, dev);
+ pr_debug("Receiving skb proto 0x%04x len %i type %i\n",
+ntohs(skb->protocol), skb->len, skb->pkt_type);
+ dev->stats.rx_bytes += skb->len;
+ dev->stats.rx_packets++;
+
+ if (hdr->flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) {
+ pr_debug("Needs csum!\n");
+ skb->ip_summed = CHECKSUM_PARTIAL;
+ skb->csum_start = hdr->csum_start;
+ skb->csum_offset = hdr->csum_offset;
+ if (skb->csum_start > skb->len - 2
+ || skb->csum_offset > skb->len - 2) {
+ if (net_ratelimit())
+ printk(KERN_WARNING "%s: csum=%u/%u len=%u\n",
+ dev->name, skb->csum_start,
+ skb->csum_offset, skb->len);
+ goto frame_err;
+ }
