Re: [PATCH]: Resurrect napi_poll patch.
From: Patrick McHardy [EMAIL PROTECTED] Date: Sat, 21 Jul 2007 07:46:39 +0200 I believe the compat attribute should work fine. One thing thing that is not explicitly supported as datatype, but works fine, is lists of attributes (using nla_for_each_attr), which looks like a good match for this case. But I think its questionable whether we should put any effort in NAPI rtnetlink support. It seems to driver specific for rtnetlink to me, and I'm not aware of any user of this. Ethtool might have its own compatibility issues, I'm not sure, but I don't think it would hurt to simply remove it from rtnetlink. Another idea is to allow the driver to decide what to do with the value. The driver will have to be involved anyways in order to iterate over the per-netdev NAPI objects. So, for example, one driver might take the given weight and distribute it evenly amongst the RX queues it has. Trying to let netlink set things on a per-queue basis is indeed cumbersom and not worth doing at all in my opinion. I however think it's not a bad idea to keep the unary weight setting around and let the driver figure out what to do with it in the multi-queue case. - 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]: Resurrect napi_poll patch.
On Fri, 2007-07-20 at 22:31 -0700, David Miller wrote: Stephen asked me if I could resurrect the last version of his napi_poll patch that I posted a long time ago, I finally got to that tonight. Basically, this disconnects the -poll() object from the net device. This will allow drivers to handle multi RX queues cleanly without creating fake net_device objects and crap like that. Hi Dave, This looks good! It might be nice though to go further and remove the internal napi_struct. It's kind of a wart for multi-queue drivers which are going to have their own array (or whatever). But I can do that as a separate patch if you think it's a decent idea. The name NAPI is also a wart, but I guess it's everywhere now so one more place isn't making things worse... Cheers, Rusty. - 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]: Resurrect napi_poll patch.
From: Rusty Russell [EMAIL PROTECTED] Date: Sat, 21 Jul 2007 17:14:31 +1000 This looks good! It might be nice though to go further and remove the internal napi_struct. It's kind of a wart for multi-queue drivers which are going to have their own array (or whatever). I guess you're suggesting to pass in a void * cookie instead of the napi_struct? You'd need to pass in a slot number or similar as well with that kind of idea, and then it starts to push the limits or worthwhileness. - 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
Virtual device lo asks to queue packet! since -git15
FYI Since -git15 (probably David's merge) I see a lot of Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! during a LTP run on a nfsroot system -Andi - 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]: Resurrect napi_poll patch.
On Sat, 2007-07-21 at 00:42 -0700, David Miller wrote: From: Rusty Russell [EMAIL PROTECTED] Date: Sat, 21 Jul 2007 17:14:31 +1000 This looks good! It might be nice though to go further and remove the internal napi_struct. It's kind of a wart for multi-queue drivers which are going to have their own array (or whatever). I guess you're suggesting to pass in a void * cookie instead of the napi_struct? You'd need to pass in a slot number or similar as well with that kind of idea, and then it starts to push the limits or worthwhileness. No, I was just thinking that drivers will put the napi_struct in their driver-specific struct (eg. struct e1000_adapter *adapter = container_of(container_of(napi, struct e1000_adapter, napi);). Multi-queue drivers will have no use for a napi_struct in net_device, right? They'll need some wrapper my_queue structure containing the napi_struct anyway. Hope that clarifies, Rusty. - 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: [Bugme-new] [Bug 8789] New: Error inserting ipt_LOG (mod_path): Device or resource busy
On Sat, 21 Jul 2007 00:44:08 -0700 (PDT) [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=8789
Summary: Error inserting ipt_LOG (mod_path): Device or resource
busy
A 2.6.12 - 2.6.22 regression.
Product: Networking
Version: 2.5
KernelVersion: 2.6.22
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: blocking
Priority: P1
Component: Netfilter/Iptables
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Most recent kernel where this bug did not occur: 2.6.21.6
Distribution: Fedora 7
Hardware Environment: irrelevant
Software Environment: Fedora 7 + vanilla kernel 2.6.22
Problem Description:
After I upgraded to 2.6.22 kernel, my iptables configuration no longer works
and I get the above error message. When the error occurs I have these iptables
modules loaded:
[EMAIL PROTECTED] sysconfig]# lsmod | egrep x._|ipt | awk '{print $1}'
xt_limit
xt_tcpudp
xt_pkttype
ipt_ULOG
xt_multiport
iptable_filter
ip_tables
x_tables
[EMAIL PROTECTED] sysconfig]# modprobe ipt_LOG
FATAL: Error inserting ipt_LOG
(/lib/modules/2.6.22-k8l/kernel/net/ipv4/netfilter/ipt_LOG.ko): Device or
resource busy
If I remove all iptables modules then I can successfully modprobe ipt_LOG.
Steps to reproduce: boot the PC or # service iptables start
-
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] endianness bug in ip6_tunnel
IPV6_TCLASS_MASK is net-endian; what happens here is that we take
a value and shove it into bits 20--27 of net-endian 32bit word.
IOW, it's misannotated (it's really htonl, not ntohl) *and* the
mask should be applied after conversion to net-endian, not before it.
The former is harmless, the latter gives the wrong value on little-endian;
As the matter of fact, on l-e it gives 0 - IPV6_TCLASS_MASK will be
htonl(0x0ff0), i.e. on little-endian we have (something 20) 0xff0...
Signed-off-by: Al Viro [EMAIL PROTECTED]
---
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -962,8 +962,8 @@ ip4ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev)
dsfield = ipv4_get_dsfield(iph);
if ((t-parms.flags IP6_TNL_F_USE_ORIG_TCLASS))
- fl.fl6_flowlabel |= ntohl(((__u32)iph-tos IPV6_TCLASS_SHIFT)
- IPV6_TCLASS_MASK);
+ fl.fl6_flowlabel |= htonl((__u32)iph-tos IPV6_TCLASS_SHIFT)
+ IPV6_TCLASS_MASK;
err = ip6_tnl_xmit2(skb, dev, dsfield, fl, encap_limit, mtu);
if (err != 0) {
-
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/3] [IrDA] Updates for 2.6.23-rc1
Hi Dave, Here go 3 minor IrDA patches that could hopefully make it to the merge window. Cheers, Samuel. - 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 1/3] [IrDA] Typo fix in irnetlink.c copyright
Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] Index: net-2.6-quilt/net/irda/irnetlink.c === --- net-2.6-quilt.orig/net/irda/irnetlink.c 2007-07-21 02:41:24.0 +0300 +++ net-2.6-quilt/net/irda/irnetlink.c 2007-07-21 02:43:00.0 +0300 @@ -1,7 +1,7 @@ /* * IrDA netlink layer, for stack configuration. * - * Copyright (c) 2007 Samuel Ortiz [EMAIL PROTECTED] + * Copyright (c) 2007 Samuel Ortiz [EMAIL PROTECTED] * * Partly based on the 802.11 nelink implementation * (see net/wireless/nl80211.c) which is: -- - 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 2/3] [IrDA] EP7211 IR driver port to the latest SIR API
The EP7211 SIR driver was the only one left without a new SIR API port.
Signed-off-by: Samuel Ortiz [EMAIL PROTECTED]
---
drivers/net/irda/Kconfig |9
drivers/net/irda/Makefile |1 +
drivers/net/irda/ep7211-sir.c | 89 +
include/linux/irda.h |1 +
4 files changed, 100 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/irda/ep7211-sir.c
Index: net-2.6-quilt/drivers/net/irda/Kconfig
===
--- net-2.6-quilt.orig/drivers/net/irda/Kconfig 2007-07-21 02:39:53.0
+0300
+++ net-2.6-quilt/drivers/net/irda/Kconfig 2007-07-21 02:39:59.0
+0300
@@ -155,6 +155,15 @@
To compile it as a module, choose M here: the module will be called
kingsun-sir.
+config EP7211_DONGLE
+ tristate EP7211 I/R support
+ depends on IRTTY_SIR ARCH_EP7211 IRDA EXPERIMENTAL
+ help
+ Say Y here if you want to build support for the Cirrus logic
+ EP7211 chipset's infrared module.
+
+
+
comment Old SIR device drivers
config IRPORT_SIR
Index: net-2.6-quilt/drivers/net/irda/Makefile
===
--- net-2.6-quilt.orig/drivers/net/irda/Makefile2007-07-21
02:39:53.0 +0300
+++ net-2.6-quilt/drivers/net/irda/Makefile 2007-07-21 02:39:59.0
+0300
@@ -45,6 +45,7 @@
obj-$(CONFIG_ACT200L_DONGLE) += act200l-sir.o
obj-$(CONFIG_MA600_DONGLE) += ma600-sir.o
obj-$(CONFIG_TOIM3232_DONGLE) += toim3232-sir.o
+obj-$(CONFIG_EP7211_DONGLE)+= ep7211-sir.o
obj-$(CONFIG_KINGSUN_DONGLE) += kingsun-sir.o
# The SIR helper module
Index: net-2.6-quilt/drivers/net/irda/ep7211-sir.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6-quilt/drivers/net/irda/ep7211-sir.c 2007-07-21 02:39:59.0
+0300
@@ -0,0 +1,89 @@
+/*
+ * IR port driver for the Cirrus Logic EP7211 processor.
+ *
+ * Copyright 2001, Blue Mug Inc. All rights reserved.
+ * Copyright 2007, Samuel Ortiz [EMAIL PROTECTED]
+ */
+#include linux/module.h
+#include linux/delay.h
+#include linux/tty.h
+#include linux/init.h
+#include linux/spinlock.h
+
+#include net/irda/irda.h
+#include net/irda/irda_device.h
+
+#include asm/io.h
+#include asm/hardware.h
+
+#include sir-dev.h
+
+#define MIN_DELAY 25 /* 15 us, but wait a little more to be sure */
+#define MAX_DELAY 1 /* 1 ms */
+
+static int ep7211_open(struct sir_dev *dev);
+static int ep7211_close(struct sir_dev *dev);
+static int ep7211_change_speed(struct sir_dev *dev, unsigned speed);
+static int ep7211_reset(struct sir_dev *dev);
+
+static struct dongle_driver ep7211 = {
+ .owner = THIS_MODULE,
+ .driver_name= EP7211 IR driver,
+ .type = IRDA_EP7211_DONGLE,
+ .open = ep7211_open,
+ .close = ep7211_close,
+ .reset = ep7211_reset,
+ .set_speed = ep7211_change_speed,
+};
+
+static int __init ep7211_sir_init(void)
+{
+ return irda_register_dongle(ep7211);
+}
+
+static void __exit ep7211_sir_cleanup(void)
+{
+ irda_unregister_dongle(ep7211);
+}
+
+static int ep7211_open(struct sir_dev *dev)
+{
+ unsigned int syscon;
+
+ /* Turn on the SIR encoder. */
+ syscon = clps_readl(SYSCON1);
+ syscon |= SYSCON1_SIREN;
+ clps_writel(syscon, SYSCON1);
+
+ return 0;
+}
+
+static int ep7211_close(struct sir_dev *dev)
+{
+ unsigned int syscon;
+
+ /* Turn off the SIR encoder. */
+ syscon = clps_readl(SYSCON1);
+ syscon = ~SYSCON1_SIREN;
+ clps_writel(syscon, SYSCON1);
+
+ return 0;
+}
+
+static int ep7211_change_speed(struct sir_dev *dev, unsigned speed)
+{
+ return 0;
+}
+
+static int ep7211_reset(struct sir_dev *dev)
+{
+ return 0;
+}
+
+MODULE_AUTHOR(Samuel Ortiz [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(EP7211 IR dongle driver);
+MODULE_LICENSE(GPL);
+MODULE_ALIAS(irda-dongle-13); /* IRDA_EP7211_DONGLE */
+
+module_init(ep7211_sir_init);
+module_exit(ep7211_sir_cleanup);
Index: net-2.6-quilt/include/linux/irda.h
===
--- net-2.6-quilt.orig/include/linux/irda.h 2007-07-21 02:39:53.0
+0300
+++ net-2.6-quilt/include/linux/irda.h 2007-07-21 02:39:59.0 +0300
@@ -77,6 +77,7 @@
IRDA_ACT200L_DONGLE = 10,
IRDA_MA600_DONGLE= 11,
IRDA_TOIM3232_DONGLE = 12,
+ IRDA_EP7211_DONGLE = 13,
} IRDA_DONGLE;
/* Protocol types to be used for SOCK_DGRAM */
--
-
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 3/3] [IrDA] TOSHIBA_FIR depends on virt_to_bus
From: Stephen Rothwell [EMAIL PROTECTED] Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] --- drivers/net/irda/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] Index: net-2.6-quilt/drivers/net/irda/Kconfig === --- net-2.6-quilt.orig/drivers/net/irda/Kconfig 2007-07-21 02:40:48.0 +0300 +++ net-2.6-quilt/drivers/net/irda/Kconfig 2007-07-21 02:40:48.0 +0300 @@ -364,7 +364,7 @@ config TOSHIBA_FIR tristate Toshiba Type-O IR Port - depends on IRDA PCI !64BIT + depends on IRDA PCI !64BIT VIRT_TO_BUS help Say Y here if you want to build support for the Toshiba Type-O IR and Donau oboe chipsets. These chipsets are used by the Toshiba -- - 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 05/10] sch_generic.c changes.
Hi Patrick,
Patrick McHardy [EMAIL PROTECTED] wrote on 07/20/2007 11:46:36 PM:
Krishna Kumar wrote:
+static inline int get_skb(struct net_device *dev, struct Qdisc *q,
+ struct sk_buff_head *blist,
+ struct sk_buff **skbp)
+{
+ if (likely(!blist) || (!skb_queue_len(blist) qdisc_qlen(q) =
1)) {
+ return likely((*skbp = dev_dequeue_skb(dev, q)) != NULL);
+ } else {
+ int max = dev-tx_queue_len - skb_queue_len(blist);
I'm assuming the driver will simply leave excess packets in the
blist for the next run.
Yes, and the next run will be scheduled even if no more xmits are called
either
due to qdisc_restart()'s call to driver returning :
BUSY : driver failed to send all, net_tx_action will handle this
later (the
case you mentioned)
OK : and qlen is 0, return 1 and __qdisc_run() will re-retry (where
blist len will become zero as driver processed EVERYTHING on
blist)
The check for tx_queue_len is wrong though,
its only a default which can be overriden and some qdiscs don't
care for it at all.
I think it should not matter whether qdiscs use this or not, or even if it
is modified (unless it is made zero in which case this breaks). The
intention behind this check is to make sure that not more than tx_queue_len
skbs are in all queues put together (q-qdisc + dev-skb_blist), otherwise
the blist can become too large and breaks the idea of tx_queue_len. Is that
a good justification ?
-void __qdisc_run(struct net_device *dev)
+void __qdisc_run(struct net_device *dev, struct sk_buff_head *blist)
And the patches should really be restructured so this change is
in the same patch changing the header and the caller, for example.
Ah, OK.
Thanks,
- KK
-
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 05/10] sch_generic.c changes.
Krishna Kumar2/India/IBM wrote on 07/21/2007 12:26:23 PM: Hi Patrick, Patrick McHardy [EMAIL PROTECTED] wrote on 07/20/2007 11:46:36 PM: The check for tx_queue_len is wrong though, its only a default which can be overriden and some qdiscs don't care for it at all. I think it should not matter whether qdiscs use this or not, or even if it is modified (unless it is made zero in which case this breaks). The intention behind this check is to make sure that not more than tx_queue_len skbs are in all queues put together (q-qdisc + dev-skb_blist), otherwise the blist can become too large and breaks the idea of tx_queue_len. Is that a good justification ? Also, if tx_queue_len is set to zero, I think my code will not execute and the existing code will break at rc = q-enqueue() (for sched's checking queue limits). - 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 04/10] net-sysfs.c changes.
Stephen Hemminger [EMAIL PROTECTED] wrote on 07/20/2007 09:52:03 PM: Patrick McHardy [EMAIL PROTECTED] wrote: Krishna Kumar2 wrote: Patrick McHardy [EMAIL PROTECTED] wrote on 07/20/2007 03:37:20 PM: rtnetlink support seems more important than sysfs to me. Thanks, I will add that as a patch. The reason to add to sysfs is that it is easier to change for a user (and similar to tx_queue_len). But since batching is so similar to TSO, i really should be part of the flags and controlled by ethtool like other offload flags. So should I add all three interfaces (or which ones) : 1. /sys (like for tx_queue_len) 2. netlink 3. ethtool. Or only 2 3 are enough ? thanks, - KK - 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 03/10] dev.c changes.
Hi Sridhar, Sridhar Samudrala [EMAIL PROTECTED] wrote on 07/20/2007 11:14:19 PM: @@ -1566,7 +1605,7 @@ gso: /* reset queue_mapping to zero */ skb-queue_mapping = 0; rc = q-enqueue(skb, q); - qdisc_run(dev); + qdisc_run(dev, NULL); OK. So you are passing a NULL blist here. However, i am not sure why batching is not used in this situation. Actually it could be used, but in most cases there will be only one skb. If I pass the blist here, the result (for batching case) will be to put one single skb into the blist and call the new xmit API. That wastes cycles as we take a skb out from the queue (as in regular code) and then add it to the blist (different in the new code) and then the driver has to remove this skb from the blist (different in the new code). I could try batching but then require there are more than 1 skbs before adding to the blist (or the blist doesn't already have skbs, in which case adding even one skb makes sense). Also, it will have a slight impact for regular drivers where for each xmit, one extra dereference for dev-skb_blist (which is always NULL) is made, which was another reason to always pass NULL. I will check what the results are by giving passing blist here too and make the above change. I will run tests for that (as well as NETPERF RR test as asked by Evgeniy). Thanks, - KK - 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 02/10] Networking include file changes.
Hi Sridhar, Sridhar Samudrala [EMAIL PROTECTED] wrote on 07/20/2007 10:55:05 PM: diff -ruNp org/include/net/pkt_sched.h new/include/net/pkt_sched.h --- org/include/net/pkt_sched.h 2007-07-20 07:49:28.0 +0530 +++ new/include/net/pkt_sched.h 2007-07-20 08:30:22.0 +0530 @@ -80,13 +80,13 @@ extern struct qdisc_rate_table *qdisc_ge struct rtattr *tab); extern void qdisc_put_rtab(struct qdisc_rate_table *tab); -extern void __qdisc_run(struct net_device *dev); +extern void __qdisc_run(struct net_device *dev, struct sk_buff_head *blist); Why do we need this additional 'blist' argument? Is this different from dev-skb_blist? It is the same, but I want to call it mostly with NULL and rarely with the batch list pointer (so it is related to your other question). My original code didn't have this and was trying batching in all cases. But in most xmit's (probably almost all), there will be only one packet in the queue to send and batching will never happen. When there is a lock contention or if the queue is stopped, then the next iteration will find 1 packets. But I still will try no batching for the lock failure case as there be probably 2 packets (one from previous time and 1 from this time, or 3 if two failures, etc), and try batching only when queue was stopped from net_tx_action (this was based on Dave Miller's idea). Thanks, - KK - 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: Linux, tcpdump and vlan
Ben Greear [EMAIL PROTECTED] writes: There is already a flag you can set on vlan devices (reorder-header) that strips the VLAN tag before presenting it to user-space. Sure, but isn't it only valid for VLAN device (not the main ethX)? I.e., can you have the tag stripped from frames captured on ethX? On tx, if it shows up on the vlan device, we add that device's VID to the header if no VID is currently in the SKB. If it is in the SKB header we change the VID to be the tx dev's VID (if it was different). This allows user-space to send a raw ethernet frame on a vlan device and have it automatically go out of the box on the correct vlan. User-space can also send raw VLAN frames and have those also go out on the correct VLAN. Well... I think the tag should be added unconditionally (for things like QinQ) but that's trivial and minor. IOW: I think all Ethernet interfaces should always be VLAN-aware, stripping the tag (only one) early on RX and adding it late on TX. That means tcpdump would see packets with exactly one tag removed (unless there was no tag), in both RX and TX. Tcpdump would need other means to get VLAN id... -- Krzysztof Halasa - 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]: Resurrect napi_poll patch.
David Miller [EMAIL PROTECTED] writes: Good candidates for taking advantage of multi-napi are: 1) e1000 2) ucc_geth 3) ehea 4) sunvnet s2io.c -Andi - 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 00/10] Implement batching skb API
I am (have been) under extreme travel mode - so i will have high latency in follow ups. On Fri, 2007-20-07 at 12:01 +0530, Krishna Kumar wrote: Hi Dave, Roland, everyone, In May, I had proposed creating an API for sending 'n' skbs to a driver to reduce lock overhead, DMA operations, and specific to drivers that have completion notification like IPoIB - reduce completion handling ([RFC] New driver API to speed up small packets xmits @ http://marc.info/?l=linux-netdevm=117880900818960w=2). I had also sent initial test results for E1000 which showed minor improvements (but also got degradations) @http://marc.info/?l=linux-netdevm=117887698405795w=2. Add to that context: that i have been putting out patches on this over the last 3+ years as well as several public presentations = last one being: http://vger.kernel.org/jamal_netconf2006.sxi My main problem (and obstacles to submitting the patches) has been a result of not doing the approriate testing - i had been testing forwarding path (in all my results post the latest patches) when i should really have been testing the improvement of the tx path. There is a parallel WIP by Jamal but the two implementations are completely different since the code bases from the start were separate. Key changes: - Use a single qdisc interface to avoid code duplication and reduce maintainability (sch_generic.c size reduces by ~9%). - Has per device configurable parameter to turn on/off batching. - qdisc_restart gets slightly modified while looking simple without any checks for batching vs regular code (infact only two lines have changed - 1. instead of dev_dequeue_skb, a new batch-aware function is called; and 2. an extra call to hard_start_xmit_batch. - No change in__qdisc_run other than a new argument (from DM's idea). - Applies to latest net-2.6.23 compared to 2.6.22-rc4 code. All the above are cosmetic differences. To me is the highest priority is making sure that batching is useful and what the limitations are. At some point, when all looks good - i dont mind adding an ethtool interface to turn off/on batching, merge with the new qdisc restart path instead of having a parallel path, solicit feedback on naming, where to allocate structs etc etc. All that is low prio if batching across a variety of hardware and applications doesnt prove useful. At the moment, i am unsure theres consistency to justify push batching in. Having said that below are the main architectural differences we have which is what we really need to discuss and see what proves useful: - Batching algo/processing is different (eg. if qdisc_restart() finds one skb in the batch list, it will try to batch more (upto a limit) instead of sending that out and batching the rest in the next call. This sounds a little more aggressive but maybe useful. I have experimented with setting upper bound limits (current patches have a pktgen interface to set the max to send) and have concluded that it is unneeded. Probing by letting the driver tell you what space is available has proven to be the best approach. I have been meaning to remove the code in pktgen which allows these limits. - Jamal's code has a separate hw prep handler called from the stack, and results are accessed in driver during xmit later. I have explained the reasoning to this a few times. A recent response to Michael Chan is here: http://marc.info/?l=linux-netdevm=118346921316657w=2 And heres a response to you that i havent heard back on: http://marc.info/?l=linux-netdevm=118355539503924w=2 My tests so far indicate this interface is useful. It doesnt apply well to some drivers (for example i dont use it in tun) - which makes it optional but useful nevertheless. I will be more than happy to kill this if i can find cases where it proves to be a bad idea. - Jamal's code has dev-xmit_win which is cached by the driver. Mine has dev-xmit_slots but this is used only by the driver while the core has a different mechanism to find how many skbs to batch. This is related to the first item. - Completely different structure/design coding styles. (This patch will work with drivers updated by Jamal, Matt Michael Chan with minor modifications - rename xmit_win to xmit_slots rename batch handler) Again, cosmetics (and indication you are morphing towards me). So if i was to sum up this, (it would be useful discussion to have on these) the real difference is: a) you have an extra check on refilling the skb list when you find that it has a single skb. I tagged this as being potentially useful. b) You have a check for some upper bound on the number of skbs to send to the driver. I tagged this as unnecessary - the interface is still on in my current code, so it shouldnt be hard to show one way or other. c) You dont have prep_xmit() Add to that list any other architectural differences
NFS mount gives ENETDOWN in -git15
I tried to mount another nfs mount on a system running with nfsroot.
But I get
# mount basil:/home /basil/home/
mount: Network is down
The network is not down of course, the system is happily running with nfs root
from that
server. Userland is older SUSE 10.0
Excerpt from strace mount:
-Andi
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(938),
sin_addr=inet_addr(0.0.0.0)}, 16) = -1 EADDRINUSE (Address already in use)
bind(3, {sa_family=AF_INET, sin_port=htons(939),
sin_addr=inet_addr(0.0.0.0)}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(900),
sin_addr=inet_addr(10.23.204.1)}, 16) = 0
uname({sys=Linux, node=bigfoot, ...}) = 0
geteuid() = 0
getegid() = 0
getgroups(0, NULL) = 1
getgroups(1, [0]) = 1
gettimeofday({1185029510, 644658}, NULL) = 0
write(3, \200\0\0Td*\362{\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\2\0..., 88) = 88
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 2) = 1
read(3, \200\0\0d*\362{\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 4000) = 64
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 5
bind(5, {sa_family=AF_INET, sin_port=htons(939),
sin_addr=inet_addr(0.0.0.0)}, 16) = -1 EADDRINUSE (Address already in use)
bind(5, {sa_family=AF_INET, sin_port=htons(940),
sin_addr=inet_addr(0.0.0.0)}, 16) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 6
bind(6, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr(0.0.0.0)},
16) = 0
connect(6, {sa_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr(10.23.204.1)}, 16) = 0
write(6, \200\0\0008i \25\301\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0..., 60) = 60
poll([{fd=6, events=POLLIN, revents=POLLIN}], 1, 6) = 1
read(6, \200\0\0\34i \25\301\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0..., 400) = 32
close(6)= 0
uname({sys=Linux, node=bigfoot, ...}) = 0
close(3)= 0
close(3)= -1 EBADF (Bad file descriptor)
rt_sigprocmask(SIG_BLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0
mount(basil:/home, /basil/home/, nfs,
MS_POSIXACL|MS_ACTIVE|MS_NOUSER|0xec, 0x51ba60) = -1 ENETDOWN (Network 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
TCP and batching WAS(Re: [PATCH 00/10] Implement batching skb API
On Fri, 2007-20-07 at 08:18 +0100, Stephen Hemminger wrote: You may see worse performance with batching in the real world when running over WAN's. Like TSO, batching will generate back to back packet trains that are subject to multi-packet synchronized loss. Has someone done any study on TSO effect? Doesnt ECN with a RED router help on something like this? I find it suprising that a single flow doing TSO would overwhelm a routers buffer. I actually think the value of batching as far as TCP is concerned is propotional to the number of flows. i.e the more flows you have the more batching you will end up doing. And if TCPs fairness is the legend talk it has been made to be, then i dont see this as problematic. BTW, something i noticed regards to GSO when testing batching: For TCP packets slightly above MDU (upto 2K), GSO gives worse performance than non-GSO. Actually has nothing to do with batching, rather it works the same way with or without batching changes. Another oddity: Looking at the flow rate from a purely packets/second (I know thats a router centric view, but i found it strange nevertheless) - you see that as packet size goes up, the pps also goes up. I tried mucking around with nagle etc, but saw no observable changes. Any insight? My expectation was that the pps would stay at least the same or get better with smaller packets (assuming theres less data to push around). 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: [RFC 0/1] lro: Generic Large Receive Offload for TCP traffic
On 7/20/07, Jan-Bernd Themann [EMAIL PROTECTED] wrote: Hi, Thanks a lot for your comments so far. This generic LRO patch differs from the last one in several points. A new interface for a receive in pages mode has been added and tested with an eHEA prototype. Seems to work well. Does this extended interface seem to be sufficient? Thank you for this! At least for me, I find it is best to try to use an interface rather than simply reading a diff. So I will port Myri10GE to use the new interface so that I can give better feedback, I'll try my best to do this by early next week. Thank you again, Drew - 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][26/37] Clean up duplicate includes in net/atm/
Hi, This patch cleans up duplicate includes in net/atm/ Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- diff --git a/net/atm/lec.c b/net/atm/lec.c index 2770fb4..59d5aa3 100644 --- a/net/atm/lec.c +++ b/net/atm/lec.c @@ -21,7 +21,6 @@ #include net/dst.h #include linux/proc_fs.h #include linux/spinlock.h -#include linux/proc_fs.h #include linux/seq_file.h /* TokenRing if needed */ - 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][27/37] Clean up duplicate includes in net/bridge/
Hi, This patch cleans up duplicate includes in net/bridge/ Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- diff --git a/net/bridge/netfilter/ebt_log.c b/net/bridge/netfilter/ebt_log.c index 031bfa4..89d0d59 100644 --- a/net/bridge/netfilter/ebt_log.c +++ b/net/bridge/netfilter/ebt_log.c @@ -9,7 +9,6 @@ * */ -#include linux/in.h #include linux/netfilter_bridge/ebtables.h #include linux/netfilter_bridge/ebt_log.h #include linux/netfilter.h diff --git a/net/bridge/netfilter/ebt_ulog.c b/net/bridge/netfilter/ebt_ulog.c index 9411db6..a31402a 100644 --- a/net/bridge/netfilter/ebt_ulog.c +++ b/net/bridge/netfilter/ebt_ulog.c @@ -36,7 +36,6 @@ #include linux/timer.h #include linux/netlink.h #include linux/netdevice.h -#include linux/module.h #include linux/netfilter_bridge/ebtables.h #include linux/netfilter_bridge/ebt_ulog.h #include net/sock.h - 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][29/37] Clean up duplicate includes in net/ipv6/
Hi, This patch cleans up duplicate includes in net/ipv6/ Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c index d67fb1e..db50114 100644 --- a/net/ipv6/tcp_ipv6.c +++ b/net/ipv6/tcp_ipv6.c @@ -56,7 +56,6 @@ #include net/inet_ecn.h #include net/protocol.h #include net/xfrm.h -#include net/addrconf.h #include net/snmp.h #include net/dsfield.h #include net/timewait_sock.h - 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][31/37] Clean up duplicate includes in net/sched/
Hi, This patch cleans up duplicate includes in net/sched/ Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- diff --git a/net/sched/act_police.c b/net/sched/act_police.c index bf90e60..6085be5 100644 --- a/net/sched/act_police.c +++ b/net/sched/act_police.c @@ -16,7 +16,6 @@ #include linux/string.h #include linux/errno.h #include linux/skbuff.h -#include linux/module.h #include linux/rtnetlink.h #include linux/init.h #include net/act_api.h - 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][30/37] Clean up duplicate includes in net/netfilter/
Hi, This patch cleans up duplicate includes in net/netfilter/ Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c index 87ad3cc..eb3fe74 100644 --- a/net/netfilter/nf_conntrack_proto_tcp.c +++ b/net/netfilter/nf_conntrack_proto_tcp.c @@ -8,7 +8,6 @@ #include linux/types.h #include linux/timer.h -#include linux/netfilter.h #include linux/module.h #include linux/in.h #include linux/tcp.h diff --git a/net/netfilter/nf_conntrack_proto_udp.c b/net/netfilter/nf_conntrack_proto_udp.c index 13d94a0..2a2fd1a 100644 --- a/net/netfilter/nf_conntrack_proto_udp.c +++ b/net/netfilter/nf_conntrack_proto_udp.c @@ -9,7 +9,6 @@ #include linux/types.h #include linux/timer.h #include linux/module.h -#include linux/netfilter.h #include linux/udp.h #include linux/seq_file.h #include linux/skbuff.h diff --git a/net/netfilter/nf_conntrack_proto_udplite.c b/net/netfilter/nf_conntrack_proto_udplite.c index 93e747b..b906b41 100644 --- a/net/netfilter/nf_conntrack_proto_udplite.c +++ b/net/netfilter/nf_conntrack_proto_udplite.c @@ -10,7 +10,6 @@ #include linux/types.h #include linux/timer.h #include linux/module.h -#include linux/netfilter.h #include linux/udp.h #include linux/seq_file.h #include linux/skbuff.h diff --git a/net/netfilter/xt_physdev.c b/net/netfilter/xt_physdev.c index f47cab7..a4bab04 100644 --- a/net/netfilter/xt_physdev.c +++ b/net/netfilter/xt_physdev.c @@ -13,7 +13,6 @@ #include linux/netfilter_bridge.h #include linux/netfilter/xt_physdev.h #include linux/netfilter/x_tables.h -#include linux/netfilter_bridge.h MODULE_LICENSE(GPL); MODULE_AUTHOR(Bart De Schuymer [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][34/37] Clean up duplicate includes in net/xfrm/
Hi, This patch cleans up duplicate includes in net/xfrm/ Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c index c3a4b0a..e67489a 100644 --- a/net/xfrm/xfrm_policy.c +++ b/net/xfrm/xfrm_policy.c @@ -23,10 +23,9 @@ #include linux/netfilter.h #include linux/module.h #include linux/cache.h +#include linux/audit.h #include net/xfrm.h #include net/ip.h -#include linux/audit.h -#include linux/cache.h #include xfrm_hash.h diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c index 38f90ca..b2552b1 100644 --- a/net/xfrm/xfrm_state.c +++ b/net/xfrm/xfrm_state.c @@ -19,9 +19,8 @@ #include linux/ipsec.h #include linux/module.h #include linux/cache.h -#include asm/uaccess.h #include linux/audit.h -#include linux/cache.h +#include asm/uaccess.h #include xfrm_hash.h - 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/37] Clean up duplicate includes in net/tipc/
Hi, This patch cleans up duplicate includes in net/tipc/ Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- diff --git a/net/tipc/port.c b/net/tipc/port.c index 5d2b9ce..7608815 100644 --- a/net/tipc/port.c +++ b/net/tipc/port.c @@ -41,7 +41,6 @@ #include addr.h #include link.h #include node.h -#include port.h #include name_table.h #include user_reg.h #include msg.h - 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] CONFIG_NET=n - lots of link time errors
Hi, enable everything from Drivers Networking, but deselect CONFIG_NET. This throws a ton of linking errors (when using CONFIG_MODULES=n), and probably unresolved symbols (MODULES=m). Happens in current -git, but I believe it dates much farther back, because this is imo just a simple Kconfig issue. I think we need to hand out a big 'if NET'-endif block in drivers/net/Kconfig. The full error log is like 120 K in size, and I doubt it would make sense to post it, given instructions above. I'll attach my (i386) .config for anyone to see it for themselves, and a patch proposal right below. Is it ok to add 'depends on NET' on NETDEVICES, or are there some network devices that can live without CONFIG_NET? Thanks, Jan === Enabling drivers from Devices Networking (in menuconfig), for example SLIP and/or PLIP, throws link time errors when CONFIG_NET itself is =n. Have CONFIG_NETDEVICES depend on CONFIG_NET. Signed-off-by: Jan Engelhardt [EMAIL PROTECTED] --- drivers/net/Kconfig |1 + 1 file changed, 1 insertion(+) Index: linux-2.6.23/drivers/net/Kconfig === --- linux-2.6.23.orig/drivers/net/Kconfig +++ linux-2.6.23/drivers/net/Kconfig @@ -5,6 +5,7 @@ menuconfig NETDEVICES default y if UML + depends on NET bool Network device support ---help--- You can say N here if you don't intend to connect your Linux box to net.config Description: application/config
Re: Virtual device lo asks to queue packet! since -git15 II
On Saturday 21 July 2007 09:49:22 Andi Kleen wrote: FYI Since -git15 (probably David's merge) I see a lot of Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! during a LTP run on a nfsroot system ... and my firefox just hung itself up trying to connect to localhost:111 (in -git16 now) Network definitely seems to have issues -Andi - 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: Virtual device lo asks to queue packet! since -git15 II
On Sat, Jul 21, 2007 at 06:49:30PM +0200, Andi Kleen ([EMAIL PROTECTED]) wrote: On Saturday 21 July 2007 09:49:22 Andi Kleen wrote: FYI Since -git15 (probably David's merge) I see a lot of Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! during a LTP run on a nfsroot system ... and my firefox just hung itself up trying to connect to localhost:111 (in -git16 now) Network definitely seems to have issues It should be in David's tree already. Patrick fixed this with folowing patch: [NET]: Fix loopback multiqueue bug The loopback device is not allocated through netdev_alloc_mq and thus has no room for the subqueue states reserved. Change the net_device subqueue array to always include at least one element. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index da7a13c..bf9399c 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -575,7 +575,7 @@ struct net_device /* The TX queue control structures */ unsigned integress_subqueue_count; - struct net_device_subqueue egress_subqueue[0]; + struct net_device_subqueue egress_subqueue[1]; }; #define to_net_dev(d) container_of(d, struct net_device, dev) diff --git a/net/core/dev.c b/net/core/dev.c index 13a0d9f..4af0207 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -3619,7 +3619,7 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name, /* ensure 32-byte alignment of both the device and private area */ alloc_size = (sizeof(*dev) + NETDEV_ALIGN_CONST + -(sizeof(struct net_device_subqueue) * queue_count)) +(sizeof(struct net_device_subqueue) * (queue_count - 1))) ~NETDEV_ALIGN_CONST; alloc_size += sizeof_priv + NETDEV_ALIGN_CONST; @@ -3637,7 +3637,7 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name, dev-priv = ((char *)dev + ((sizeof(struct net_device) + (sizeof(struct net_device_subqueue) * - queue_count) + NETDEV_ALIGN_CONST) + (queue_count - 1)) + NETDEV_ALIGN_CONST) ~NETDEV_ALIGN_CONST)); } -Andi -- Evgeniy Polyakov - 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
[BUG] Open Kernel Bugs
This is the first listing of the open bugs that will be sent out and will contain bugs on specific areas. The bugs on the list below are about a year old and most of them confirmed (or claimed) to still be a problem. It would be appreciated if the corresponding maintenance team could take a look, close off any which are fixed and see if we can fix any which aren't. NOTE: when replying to this email, please add the bug number to the Subject in the form [Bug 1234] so that bugzilla will capture the discussion. Thanks. bugzilla: timers [BUG 7967] TIMER_ABSTIME cleared resulting in userland deadlock http://bugzilla.kernel.org/show_bug.cgi?id=7967 bugzilla: parallel [BUG 7492] parport doesn't work if DMA is used http://bugzilla.kernel.org/show_bug.cgi?id=7492 bugzilla: network [BUG 8106] tx_errors and tx_fifo_errors not updated consistantly http://bugzilla.kernel.org/show_bug.cgi?id=8106 - error reporting [BUG 7856] b44 WOL problem (bcm4401) http://bugzilla.kernel.org/show_bug.cgi?id=7856 [BUG 5839] uli526x partially recognizing interface http://bugzilla.kernel.org/show_bug.cgi?id=5839 [BUG 6613] iptables broken on 32-bit PReP (ARCH=ppc) http://bugzilla.kernel.org/show_bug.cgi?id=6613 bugzilla: sound (ALSA) [BUG 7195] pc doesn't correctly shut down because of hda_intel http://bugzilla.kernel.org/show_bug.cgi?id=7195 [BUG 6244] cs46xx in Thinkapad A21m after suspend/resume doesn't play http://bugzilla.kernel.org/process_bug.cgi?id=6244 bugzilla: scheduler [BUG 7372] Unusable system (ie slow) when copying large files. http://bugzilla.kernel.org/show_bug.cgi?id=7372 bugzilla: input [BUG 7746] Support for unicode dead keys http://bugzilla.kernel.org/show_bug.cgi?id=7746 [BUG 7941] The atkbd module makes system unusable http://bugzilla.kernel.org/process_bug.cgi?id=7941 bugzilla: dvb-usb [BUG 8179] Yuan ub300 card not working/tuning http://bugzilla.kernel.org/show_bug.cgi?id=8179 bugzilla: PCI [BUG 7528] pci=assign-busses needed on DELL Latitude D810 http://bugzilla.kernel.org/show_bug.cgi?id=7528 [BUG 8187] 2.6.20 PCI: Quirks patch breaks X11 on I82801 http://bugzilla.kernel.org/show_bug.cgi?id=8187 [BUG 7917] PCI: Failed to allocate mem resource for PCI E-to-PCI Bridge http://bugzilla.kernel.org/show_bug.cgi?id=7917 bugzilla: i386 [BUG 5565] Guess of i386 APIC PTE area scribble http://bugzilla.kernel.org/show_bug.cgi?id=5565 [BUG 7589] libata: does not work anymore on VIA VT8251 AHCI/SATA 4-Port Controller http://bugzilla.kernel.org/show_bug.cgi?id=7589 bugzilla: Interrupts [BUG 7673] Memory card reader 5-in-1 don't working on Lenovo N100 3000 http://bugzilla.kernel.org/show_bug.cgi?id=7673 bugzilla: I/O - Storage [BUG 7921] oops in 2.6.20-rc6-git3 udf pktcdvd http://bugzilla.kernel.org/show_bug.cgi?id=7921 [BUG 7507] pata_it821x: system freezes http://bugzilla.kernel.org/show_bug.cgi?id=7507 [BUG 7506] it821x: long wait time due to dma_timer_expiry http://bugzilla.kernel.org/show_bug.cgi?id=7506 [BUG 7703] hpt366 does not find drives http://bugzilla.kernel.org/show_bug.cgi?id=7703 [BUG 6516] wrong value for avgqu-sz http://bugzilla.kernel.org/show_bug.cgi?id=6516 bugzilla: serial [BUG 7750] open/close loop causes disabled irq http://bugzilla.kernel.org/show_bug.cgi?id=7750 bugzilla: PCMCIA [BUG 7788] System freeze as soon as PCMCIA card is inserted http://bugzilla.kernel.org/show_bug.cgi?id=7788 [BUG 8118] Wrong device identifiers returned in lspci for pccard with RL5c476 II (rev 80) http://bugzilla.kernel.org/show_bug.cgi?id=8118 [BUG 8262] PCMCIA: socket *** DANGER *** unable to remove socket power http://bugzilla.kernel.org/show_bug.cgi?id=8262 [BUG 7215] PCMCIA network card causes either X or kernel to freeze http://bugzilla.kernel.org/show_bug.cgi?id=7215 bugzilla: SCSI [BUG 4880] dpt_i2o.c does not register itself with sysfs http://bugzilla.kernel.org/show_bug.cgi?id=4880 bugzilla: File Systems [BUG 6124] mount of UDF fs ignores UID and GID options http://bugzilla.kernel.org/show_bug.cgi?id=6124 bugzilla: USB [BUG 8104] kernel floods console with connect-debounce failed http://bugzilla.kernel.org/show_bug.cgi?id=8104 - - - --- - 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: Linux, tcpdump and vlan
Krzysztof Halasa wrote: Ben Greear [EMAIL PROTECTED] writes: There is already a flag you can set on vlan devices (reorder-header) that strips the VLAN tag before presenting it to user-space. Sure, but isn't it only valid for VLAN device (not the main ethX)? I.e., can you have the tag stripped from frames captured on ethX? No. I don't see a good reason to strip on ethX. That hardware accel VLANs strip is an inconvenience in my opinion, no need to force it in software as well. On tx, if it shows up on the vlan device, we add that device's VID to the header if no VID is currently in the SKB. If it is in the SKB header we change the VID to be the tx dev's VID (if it was different). This allows user-space to send a raw ethernet frame on a vlan device and have it automatically go out of the box on the correct vlan. User-space can also send raw VLAN frames and have those also go out on the correct VLAN. Well... I think the tag should be added unconditionally (for things like QinQ) but that's trivial and minor. I think that for Q in Q, we would need some explicit flag on each skb to know when to add or modify the VID. I was never able to think of an automatic solution that worked in all cases (bridging, writing raw packets from user space, normal receive, normal transmit, ...) Modifying the bridging code would fix that path, and adding a socket opt to deal with writing raw packets from user-space should handle the other tricky case I believe. IOW: I think all Ethernet interfaces should always be VLAN-aware, stripping the tag (only one) early on RX and adding it late on TX. That means tcpdump would see packets with exactly one tag removed (unless there was no tag), in both RX and TX. Tcpdump would need other means to get VLAN id... What benefit will this add? It will certainly decrease performance to copy around the header for every VLAN packet, so there would have to be a good reason to add this logic... Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - 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] Allow LSM to use IP address/port number.
--- Tetsuo Handa [EMAIL PROTECTED] wrote:
Hello.
Patrick McHardy wrote:
Quoting Tetsuo:
So, my approach is not using security context associated with a socket
but security context associated with a process.
Isn't the socket context derived from the process context?
Not so regarding my case.
static int smack_sk_alloc_security(struct sock *sk, int family, gfp_t
priority)
{
sk-sk_security = current-security;
return 0;
}
will not help what I want to do.
So, I'm not planning to use sk-sk_security.
Before you go too far down this path please note that the quoted
code is bad* because back pointers from sockets to tasks can't be
reliable. See later versions for more reasonable behavior.
I'm planning to use current-security at accept()/recvmsg() time.
The delivery of packets and the completion of these syscalls are
related but independent events. Be careful about the relationship
between the events and the placement of your checks.
* Stephen had good comments on the details on list earlier.
Casey Schaufler
[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: Question: how to detect if a qdisc is root or not?
From: Patrick McHardy [EMAIL PROTECTED] Date: Sat, 21 Jul 2007 06:01:07 +0200 Waskiewicz Jr, Peter P wrote: I just sent out a patch to fix this. I didn't see it yet. VGER ate it for some reason and I didn't notice it during my daily bounce analysis. I asked him on IRC to resend it, but he's away from the computer already :) I'll get it resent today. Sorry for the delay. -PJ - 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: Virtual device lo asks to queue packet! since -git15
From: Andi Kleen [EMAIL PROTECTED] Date: Sat, 21 Jul 2007 09:49:22 +0200 Since -git15 (probably David's merge) I see a lot of Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! during a LTP run on a nfsroot system Yes I have a fix pending in my tree for this. commit 31ce72a6b1c7635259cf522459539c0611f2c50c Author: Patrick McHardy [EMAIL PROTECTED] Date: Fri Jul 20 19:45:45 2007 -0700 [NET]: Fix loopback crashes when multiqueue is enabled. From: Patrick McHardy [EMAIL PROTECTED] Signed-off-by: David S. Miller [EMAIL PROTECTED] diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 9820ca1..4a616d7 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -575,7 +575,7 @@ struct net_device /* The TX queue control structures */ unsigned integress_subqueue_count; - struct net_device_subqueue egress_subqueue[0]; + struct net_device_subqueue egress_subqueue[1]; }; #define to_net_dev(d) container_of(d, struct net_device, dev) diff --git a/net/core/dev.c b/net/core/dev.c index 38212c3..ee40355 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -3624,7 +3624,7 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name, /* ensure 32-byte alignment of both the device and private area */ alloc_size = (sizeof(*dev) + NETDEV_ALIGN_CONST + -(sizeof(struct net_device_subqueue) * queue_count)) +(sizeof(struct net_device_subqueue) * (queue_count - 1))) ~NETDEV_ALIGN_CONST; alloc_size += sizeof_priv + NETDEV_ALIGN_CONST; @@ -3642,7 +3642,7 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name, dev-priv = ((char *)dev + ((sizeof(struct net_device) + (sizeof(struct net_device_subqueue) * - queue_count) + NETDEV_ALIGN_CONST) + (queue_count - 1)) + NETDEV_ALIGN_CONST) ~NETDEV_ALIGN_CONST)); } - 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]: Resurrect napi_poll patch.
From: Rusty Russell [EMAIL PROTECTED] Date: Sat, 21 Jul 2007 18:00:11 +1000 No, I was just thinking that drivers will put the napi_struct in their driver-specific struct (eg. struct e1000_adapter *adapter = container_of(container_of(napi, struct e1000_adapter, napi);). That works. Multi-queue drivers will have no use for a napi_struct in net_device, right? They'll need some wrapper my_queue structure containing the napi_struct anyway. Sure, we can eliminate the napi_struct in struct net_device eventually. But then again, like the statistics, if it's convenient to just use the in-net_device one then why not :) - 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: Question: how to detect if a qdisc is root or not?
Anyways, I tried a few different things, and what it looks like is sch-parent will be NULL (0) for the top-level device. This is sch-correct, and trying to mess with that screws up qdisc_graft() when unloading the qdisc. I also tried adding a TCQ_F_ROOT flag to sch-flags when classid is TC_H_ROOT, but that also screwed up unloading the qdisc. I dont think I understand. Whats the problem with setting sch-parent on initialization instead on grafting as I did in my example patch? Please explain the problems arrising on unload in detail. sch-parent is getting set on initialization, and for the root and ingress qdiscs, it's left at zero. If I change that value, when the root qdisc is unloaded and pfifo_fast is put back into place, the qdisc_destroy() walks the tree and attempts to free memory from the handle pointed at by sch-parent. It stops when sch-parent is NULL, so sch-parent is actually being set as intended. The only thing that confused me is that nowhere in the qdisc is TC_H_ROOT included explicitly, rather, the root qdisc is where sch-parent is NULL. So I misunderstood what was actually wrong. The qdisc code is ok as-is, it's just that the top-level qdisc (root and ingress) have a sch-parent of NULL, which is being set correctly today. Hope that clarifies. Thanks, -PJ - 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] NET: Fix sch_prio to detect the root qdisc loading
The sch-parent handle will be NULL for the scheduler that is TC_H_ROOT.
Change this check in prio_tune() so that only the root qdisc can be
multiqueue-enabled.
Signed-off-by: Peter P Waskiewicz Jr [EMAIL PROTECTED]
---
net/sched/sch_prio.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/sched/sch_prio.c b/net/sched/sch_prio.c
index 2d8c084..271051e 100644
--- a/net/sched/sch_prio.c
+++ b/net/sched/sch_prio.c
@@ -239,11 +239,13 @@ static int prio_tune(struct Qdisc *sch, struct rtattr
*opt)
/* If we're multiqueue, make sure the number of incoming bands
* matches the number of queues on the device we're associating with.
* If the number of bands requested is zero, then set q-bands to
-* dev-egress_subqueue_count.
+* dev-egress_subqueue_count. Also, the root qdisc must be the
+* only one that is enabled for multiqueue, since it's the only one
+* that interacts with the underlying device.
*/
q-mq = RTA_GET_FLAG(tb[TCA_PRIO_MQ - 1]);
if (q-mq) {
- if (sch-handle != TC_H_ROOT)
+ if (sch-parent != NULL)
return -EINVAL;
if (netif_is_multiqueue(sch-dev)) {
if (q-bands == 0)
-
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: Linux, tcpdump and vlan
Ben Greear [EMAIL PROTECTED] writes: IOW: I think all Ethernet interfaces should always be VLAN-aware, stripping the tag (only one) early on RX and adding it late on TX. That means tcpdump would see packets with exactly one tag removed (unless there was no tag), in both RX and TX. Tcpdump would need other means to get VLAN id... What benefit will this add? It will certainly decrease performance to copy around the header for every VLAN packet, so there would have to be a good reason to add this logic... I'd have to do some tests... Hopefully in this decade, forget it for now. The primary reason - consistency with hw VLAN cards - simpler code. The performance is already decreased (not sure if it's noticeable) most of the time, i.e., when not transparently bridging VLAN trunks. Bridging VLAN trunks is, of course, theoretically possible, but it's rather not a common operation when using .1Q. That is, with header reordering, of course. Anyway, -ENOPATCH from me for now. -- Krzysztof Halasa - 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: Virtual device lo asks to queue packet! since -git15
On Saturday 21 July 2007 20:53:04 David Miller wrote: From: Andi Kleen [EMAIL PROTECTED] Date: Sat, 21 Jul 2007 09:49:22 +0200 Since -git15 (probably David's merge) I see a lot of Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! Virtual device lo asks to queue packet! during a LTP run on a nfsroot system Yes I have a fix pending in my tree for this. Thanks. Could this explain the firefox hangs too? -Andi - 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] 3c59x, check return of pci_enable_device()
commit 36d139ccebba6a1082b743fbedb53c5a5097987c
Author: Mark Hindley [EMAIL PROTECTED]
Date: Sat Jul 21 22:56:08 2007 +0100
Check return of pci_enable_device in vortex_up().
Signed-off-by: Mark Hindley [EMAIL PROTECTED]
diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
index f26ca33..192e74b 100644
--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -1490,13 +1490,17 @@ vortex_up(struct net_device *dev)
struct vortex_private *vp = netdev_priv(dev);
void __iomem *ioaddr = vp-ioaddr;
unsigned int config;
- int i, mii_reg1, mii_reg5;
+ int i, mii_reg1, mii_reg5, err;
if (VORTEX_PCI(vp)) {
pci_set_power_state(VORTEX_PCI(vp), PCI_D0);/* Go active */
if (vp-pm_state_valid)
pci_restore_state(VORTEX_PCI(vp));
- pci_enable_device(VORTEX_PCI(vp));
+ err = pci_enable_device(VORTEX_PCI(vp));
+ if (err) {
+ printk(KERN_WARNING %s: Could not enable device \n,
+ dev-name);
+ }
}
/* Before initializing select the active media port. */
-
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]: Resurrect napi_poll patch.
On Sat, 2007-07-21 at 11:54 -0700, David Miller wrote: From: Rusty Russell [EMAIL PROTECTED] Date: Sat, 21 Jul 2007 18:00:11 +1000 No, I was just thinking that drivers will put the napi_struct in their driver-specific struct (eg. struct e1000_adapter *adapter = container_of(container_of(napi, struct e1000_adapter, napi);). That works. Multi-queue drivers will have no use for a napi_struct in net_device, right? They'll need some wrapper my_queue structure containing the napi_struct anyway. Sure, we can eliminate the napi_struct in struct net_device eventually. But then again, like the statistics, if it's convenient to just use the in-net_device one then why not :) Because *every* single driver can use the in-net_device stats. In five years' time, the napi_struct for simple drivers in net_device will look confusing. Since your change touches all NAPI drivers anyway, it'd be nice to go straight to everyone allocates their own NAPI struct in one jump. Cheers, Rusty. - 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]: Resurrect napi_poll patch.
From: Rusty Russell [EMAIL PROTECTED] Date: Sun, 22 Jul 2007 09:10:23 +1000 In five years' time, the napi_struct for simple drivers in net_device will look confusing. Since your change touches all NAPI drivers anyway, it'd be nice to go straight to everyone allocates their own NAPI struct in one jump. Good point. But note that you'd be adding a pointer deref, the current sequence: napi_struct -- netdev -- driver_private involves all pointer arithmetic and no derefs, whereas: napi_struct -- driver_private -- netdev will involve at least on deref to get to the netdev from the driver_private. (Ignore the fact that netdev_priv() is not currently optimized as it used to be, that's an abberation of the current multi-queue implementation and will be fixed). So this suggestion does have real downsides. - 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] [IrDA] Typo fix in irnetlink.c copyright
From: [EMAIL PROTECTED] Date: Sat, 21 Jul 2007 11:13:05 +0300 Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] Applied. - 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/3] [IrDA] EP7211 IR driver port to the latest SIR API
From: [EMAIL PROTECTED] Date: Sat, 21 Jul 2007 11:13:06 +0300 The EP7211 SIR driver was the only one left without a new SIR API port. Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] Applied. - 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 3/3] [IrDA] TOSHIBA_FIR depends on virt_to_bus
From: [EMAIL PROTECTED] Date: Sat, 21 Jul 2007 11:13:07 +0300 From: Stephen Rothwell [EMAIL PROTECTED] Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] Also 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: [PATCH] endianness bug in ip6_tunnel
From: Al Viro [EMAIL PROTECTED] Date: Sat, 21 Jul 2007 09:12:31 +0100 IPV6_TCLASS_MASK is net-endian; what happens here is that we take a value and shove it into bits 20--27 of net-endian 32bit word. IOW, it's misannotated (it's really htonl, not ntohl) *and* the mask should be applied after conversion to net-endian, not before it. The former is harmless, the latter gives the wrong value on little-endian; As the matter of fact, on l-e it gives 0 - IPV6_TCLASS_MASK will be htonl(0x0ff0), i.e. on little-endian we have (something 20) 0xff0... Signed-off-by: Al Viro [EMAIL PROTECTED] Applied, thanks Al. - 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] CONFIG_NET=n - lots of link time errors
From: Jan Engelhardt [EMAIL PROTECTED] Date: Sat, 21 Jul 2007 18:27:38 +0200 (CEST) Enabling drivers from Devices Networking (in menuconfig), for example SLIP and/or PLIP, throws link time errors when CONFIG_NET itself is =n. Have CONFIG_NETDEVICES depend on CONFIG_NET. Signed-off-by: Jan Engelhardt [EMAIL PROTECTED] This is the second time I've seen this change in the past few days, and people seem to hit it quite readily with randconfig. It seems reasonable and I'll apply it, thanks Jan. - 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 1/1] lro: Generic Large Receive Offload for TCP traffic
From: Jan-Bernd Themann [EMAIL PROTECTED] Date: Fri, 20 Jul 2007 17:41:48 +0200 Generic LRO patch Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED] I have no general objections to this patch. However I'd like to see at least one or two uses of these APIs before we put it in, and it sounds as if we have at least two pending and in the works if not ready already, so that shouldn't be an issue. 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] NET: Add missing entries to family name tables
From: David Howells [EMAIL PROTECTED] Date: Fri, 20 Jul 2007 10:53:25 +0100 Add missing entries to af_family_clock_key_strings[]. Signed-off-by: David Howells [EMAIL PROTECTED] Applied, thanks David. - 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]: Resurrect napi_poll patch.
On Sat, 2007-07-21 at 18:59 -0700, David Miller wrote: But note that you'd be adding a pointer deref, the current sequence: napi_struct -- netdev -- driver_private involves all pointer arithmetic and no derefs, whereas: napi_struct -- driver_private -- netdev will involve at least on deref to get to the netdev from the driver_private. (Ignore the fact that netdev_priv() is not currently optimized as it used to be, that's an abberation of the current multi-queue implementation and will be fixed). So this suggestion does have real downsides. But if netdev - driver_private can be optimized, so can driver_private - netdev. We just don't have a wrapper for it. netdev_of() perhaps? (If it can't be implemented by ptr arith, we have to do some allocation tricks to hide the dev ptr before driver_private, but it's still implementable). Perhaps we should do this anyway: it's another every driver wants it kind of deal AFAICT... Cheers, Rusty. - 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]: Resurrect napi_poll patch.
From: Rusty Russell [EMAIL PROTECTED] Date: Sun, 22 Jul 2007 12:39:32 +1000 But if netdev - driver_private can be optimized, so can driver_private - netdev. We just don't have a wrapper for it. netdev_of() perhaps? (If it can't be implemented by ptr arith, we have to do some allocation tricks to hide the dev ptr before driver_private, but it's still implementable). Perhaps we should do this anyway: it's another every driver wants it kind of deal AFAICT... Color me convinced :-) Ok, I'll put the napi_struct info the driver private and respin the patch. - 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
