* Re: [net-next-2.6 PATCH] net: fast consecutive name allocation
From: Stephen Hemminger @ 2009-11-15 1:22 UTC (permalink / raw)
To: Mark Smith; +Cc: David Miller, bcrl, opurdila, eric.dumazet, netdev
In-Reply-To: <20091115090604.331d75c2@opy.nosense.org>
On Sun, 15 Nov 2009 09:06:04 +1030
Mark Smith <lk-netdev@lk-netdev.nosense.org> wrote:
> The fundamental purpose of PPPoE is nothing to do with any scaling or
> architecture, it is purely to make a more modern shared networking
> technology like Ethernet look like high speed dial up. This has occurred
> mainly because when broadband came along it allowed ISPs to introduce
> it quickly, without having to also upgrade their dial up oriented
> backend systems i.e. customer authentication/accounting and customer
> support systems. It wasn't ideal then and it isn't ideal now. PPPoE adds
> an overhead of 8 bytes per packet, yet the only thing it is doing is
> changing ethernet from multipoint to point-to-point so PPP can run
> over it and providing ISPs with an ability to identify the subscriber.
> There are other methods to solve customer identity problem without the
> PPPoE overheads. Moving to them however can be a long drawn out process
> because it also means changes to customer's CPE settings, or running
> the old and new methods in parallel for the foreseeable future.
Carriers still haven't figured out that circuit switched networks don't
scale. They just can't learn the lesson of the Internet.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net: fast consecutive name allocation
From: Mark Smith @ 2009-11-14 22:36 UTC (permalink / raw)
To: David Miller; +Cc: bcrl, shemminger, opurdila, eric.dumazet, netdev
In-Reply-To: <20091113.185937.251557071.davem@davemloft.net>
On Fri, 13 Nov 2009 18:59:37 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Benjamin LaHaise <bcrl@lhnet.ca>
> Date: Fri, 13 Nov 2009 18:52:10 -0500
>
> > If you don't want the overhead from this kind of scaling, stick it under a
> > config option, but please don't stop other people from pushing Linux into
> > new uses which have these scaling requirements.
>
> This 'scaling requirement' only exists in environments where people
> undersubsribe their networks, right?
>
> I'm not saying we won't put scaling into these areas, I'm just trying
> to make a point to show that this "need" only exists because people
> have purposefully created these situations where they feel the need to
> massively control their users usage in order to generate revenue.
I'm don't understand that comment, and I work for (and
designed most of the infrastructure for) an ISP that usually has
well over 40 000 concurrent PPPoE sesssions at any one time.
The fundamental purpose of PPPoE is nothing to do with any scaling or
architecture, it is purely to make a more modern shared networking
technology like Ethernet look like high speed dial up. This has occurred
mainly because when broadband came along it allowed ISPs to introduce
it quickly, without having to also upgrade their dial up oriented
backend systems i.e. customer authentication/accounting and customer
support systems. It wasn't ideal then and it isn't ideal now. PPPoE adds
an overhead of 8 bytes per packet, yet the only thing it is doing is
changing ethernet from multipoint to point-to-point so PPP can run
over it and providing ISPs with an ability to identify the subscriber.
There are other methods to solve customer identity problem without the
PPPoE overheads. Moving to them however can be a long drawn out process
because it also means changes to customer's CPE settings, or running
the old and new methods in parallel for the foreseeable future.
On the occasions I've looked at whether a Linux box would be an
alternative to the Cisco BRAS platform we use, the last time I looked
the number of sessions people were saying they were running was
500. I don't consider Linux to be feasible in that role until you're
able to run at least 5000 sessions on a single box. I'm a bit unusual
in that regard, as I prefer the "lots of smaller, increase chances
of failure, but consequences of failure" model - you manage the
larger number of them via configuration templating / scripted
change deployment. You need to chose your subscriber per device level,
and if 500 is the current limit for Linux, then in my opinion it is
currently too low for my application. Others in the industry might
consider 5000 too low, as they are running devices that can handle 32
000 or 64 000 PPPoE sessions.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Sharing VF device among Xen VMs
From: Satish Chowdhury @ 2009-11-14 19:49 UTC (permalink / raw)
To: netdev
In-Reply-To: <be5d34890911130925j7b7d70f3j1f205b9ad7624b76@mail.gmail.com>
Hi,
I am trying to verify a situation where VMs share a VF device of Intel
82576 dual port for data traffic.
Setup:
Case -1: On a Vt-d machine Xen(xen-1) is installed. On dom0 multiple
VFs are created for 82576ET dual port card. One of the VF is
pass-through to a VM. Now, the VM again has Xen (xen-2) installed.
So, the VMs of Xen-2 have to share the passthrough VF device for data
traffic.
Will I be able to send data from Xen-2 VMs to external world?
I had issues while creating VMs for Xen2. So, could not do the experiment.
Case-2: On Xen-1 itself I loaded igbvf driver. Changed xen
configuration to make VF as default interface on dom0. Now VMs of
Xen-1 should share the VF device.
Ping from VF interface on VM and PF ip address works.
Ping between VMs goes through.
But, ping from domU to another machine on same network on switch doesn't work.
The arp broadcast request goes out through VF interface. But the arp
reply doesn't reach VF interface, they get routed to PF interface. If
PF interface to the bridge on dom0 then ping from VMs to external
machine work.
In my experiment, the arp reply that reaches the NIC, has mac address
of interface on VM(domU). 82576 performs L2 filtering based on VF MAC
address. So, packet is not queued to VF interface.
Is it possible to add VMs mac address to L2 filtering pool of the NIC?
Regards,
-Satish
^ permalink raw reply
* [net-next 2/2] iwmc3200top: simplify the driver version
From: Tomas Winkler @ 2009-11-14 18:36 UTC (permalink / raw)
To: davem, netdev, linux-mmc
Cc: yi.zhu, inaky.perez-gonzalez, guy.cohen, ron.rindjunsky,
Tomas Winkler
In-Reply-To: <1258223796-8486-1-git-send-email-tomas.winkler@intel.com>
drop the version parts not needed for in-tree driver
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
drivers/misc/iwmc3200top/main.c | 16 +---------------
1 files changed, 1 insertions(+), 15 deletions(-)
diff --git a/drivers/misc/iwmc3200top/main.c b/drivers/misc/iwmc3200top/main.c
index a1ce97e..02b3dad 100644
--- a/drivers/misc/iwmc3200top/main.c
+++ b/drivers/misc/iwmc3200top/main.c
@@ -41,21 +41,7 @@
#define DRIVER_DESCRIPTION "Intel(R) IWMC 3200 Top Driver"
#define DRIVER_COPYRIGHT "Copyright (c) 2008 Intel Corporation."
-#define IWMCT_VERSION "0.1.62"
-
-#ifdef REPOSITORY_LABEL
-#define RL REPOSITORY_LABEL
-#else
-#define RL local
-#endif
-
-#ifdef CONFIG_IWMC3200TOP_DEBUG
-#define VD "-d"
-#else
-#define VD
-#endif
-
-#define DRIVER_VERSION IWMCT_VERSION "-" __stringify(RL) VD
+#define DRIVER_VERSION "0.1.62"
MODULE_DESCRIPTION(DRIVER_DESCRIPTION);
MODULE_VERSION(DRIVER_VERSION);
--
1.6.0.6
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* [net-next 1/2] iwmc3200top: use prefered style for the device table.
From: Tomas Winkler @ 2009-11-14 18:36 UTC (permalink / raw)
To: davem, netdev, linux-mmc
Cc: yi.zhu, inaky.perez-gonzalez, guy.cohen, ron.rindjunsky,
Tomas Winkler
Use device id number directly accompany with
comment rather then a #define
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
drivers/misc/iwmc3200top/main.c | 14 +++-----------
1 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/misc/iwmc3200top/main.c b/drivers/misc/iwmc3200top/main.c
index 6e4e491..a1ce97e 100644
--- a/drivers/misc/iwmc3200top/main.c
+++ b/drivers/misc/iwmc3200top/main.c
@@ -62,15 +62,6 @@ MODULE_VERSION(DRIVER_VERSION);
MODULE_LICENSE("GPL");
MODULE_AUTHOR(DRIVER_COPYRIGHT);
-
-/* FIXME: These can be found in sdio_ids.h in newer kernels */
-#ifndef SDIO_INTEL_VENDOR_ID
-#define SDIO_INTEL_VENDOR_ID 0x0089
-#endif
-#ifndef SDIO_DEVICE_ID_INTEL_IWMC3200TOP
-#define SDIO_DEVICE_ID_INTEL_IWMC3200TOP 0x1404
-#endif
-
/*
* This workers main task is to wait for OP_OPR_ALIVE
* from TOP FW until ALIVE_MSG_TIMOUT timeout is elapsed.
@@ -662,8 +653,9 @@ static void iwmct_remove(struct sdio_func *func)
static const struct sdio_device_id iwmct_ids[] = {
- { SDIO_DEVICE(SDIO_INTEL_VENDOR_ID, SDIO_DEVICE_ID_INTEL_IWMC3200TOP)},
- { /* end: all zeroes */ },
+ /* Intel Wireless MultiCom 3200 Top Driver */
+ { SDIO_DEVICE(SDIO_VENDOR_ID_INTEL, 0x1404)},
+ { }, /* Terminating entry */
};
MODULE_DEVICE_TABLE(sdio, iwmct_ids);
--
1.6.0.6
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* [net-next-2.6 PATCH v2] allow access to sysfs_groups member
From: Kurt Van Dijck @ 2009-11-14 16:54 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Oliver Hartkopp, Wolfgang Grandegger, netdev
In-Reply-To: <20091113142738.1aa81a03@s6510>
On Fri, Nov 13, 2009 at 02:27:38PM -0800, Stephen Hemminger wrote:
> On Fri, 13 Nov 2009 11:51:57 +0100
> Kurt Van Dijck <kurt.van.dijck@eia.be> wrote:
[...]
> EXPORT_SYMBOL_GPL() for all device/sysfs related stuff.
Ok, no problem
>
> Also, need some way to BUG() if this is done after device has
> been registered.
Ok. I gave it a try. I _think_ I did it write, but a second look would
not harm :-). I was not able to run a real test yet.
>
> Another way to add sub-directories which is what bridge, bonding,
> and others do is to use another kobject. I think this is what you
> want for the case of two CAN objects under one netdevice.
In fact, I wanted to add this for cards that have multiple seperate CAN
network device, combined on 1 PCI or PCMCIA device.
In the 'add network' uevent, a udev rule could find properties of the
card (device/ symlink). Right now, there is no way to tell if a network
device is bus 1 or 2 on the card. in CAN, there's no such thing as a MAC
address.
I encountered this issue with a softing CAN card (not yet in mainline),
and there are other drivers in the socketCAN queue that have the same
problem.
The ethernet cards with multiple busses (that I've seen yet :-) )
combine multiple PCI devices on 1 card, and identification of the
'instance on the card' can happen with the sysfs properties delivered by
the PCI bus.
CAN devices with multiple busses typically are combined all together on
1 single device on the PCI or PCMCIA bus.
So, I wanted to add a 'channel' property in /sys/class/net/canX, which
could indicate the instance on the device. Such property must be
installed by the driver, not the bus the device is on.
This patch allows me to have this channel property present at the moment
of the uevent.
I can imagine other subsystems may benefit from this too.
Regards,
Kurt Van Dijck
---
This patch allows adding sysfs attribute groups during netdevice registration.
The idea is that before the register_netdev call, several calls to
netdev_sysfs_add_group can be done.
Signed-off-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
---
include/linux/netdevice.h | 2 ++
net/core/net-sysfs.c | 29 ++++++++++++++++++++++++-----
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 8380009..ebfc789 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1115,6 +1115,8 @@ extern int dev_open(struct net_device *dev);
extern int dev_close(struct net_device *dev);
extern void dev_disable_lro(struct net_device *dev);
extern int dev_queue_xmit(struct sk_buff *skb);
+extern int netdev_sysfs_add_group(struct net_device *net,
+ const struct attribute_group *grp);
extern int register_netdevice(struct net_device *dev);
extern void unregister_netdevice(struct net_device *dev);
extern void free_netdev(struct net_device *dev);
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 753c420..6451e9a 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -527,27 +527,46 @@ void netdev_unregister_kobject(struct net_device * net)
device_del(dev);
}
+/* Add a sysfs group to the netdev groups */
+int netdev_sysfs_add_group(struct net_device *net,
+ const struct attribute_group *grp)
+{
+ struct attribute_group **groups = net->sysfs_groups;
+ struct attribute_group **end;
+
+ BUG_ON(net->reg_state >= NETREG_REGISTERED);
+ /* end pointer, with room for null terminator */
+ end = &net->sysfs_groups[ARRAY_SIZE(net->sysfs_groups) - 1];
+ for (; groups < end; ++groups) {
+ if (!*groups) {
+ *groups = grp;
+ return 0;
+ }
+ }
+ return -ENOSPC;
+}
+EXPORT_SYMBOL_GPL(netdev_sysfs_add_group);
+
/* Create sysfs entries for network device. */
int netdev_register_kobject(struct net_device *net)
{
struct device *dev = &(net->dev);
- const struct attribute_group **groups = net->sysfs_groups;
dev->class = &net_class;
dev->platform_data = net;
- dev->groups = groups;
+ dev->groups = net->sysfs_groups;
dev_set_name(dev, "%s", net->name);
#ifdef CONFIG_SYSFS
- *groups++ = &netstat_group;
+ netdev_sysfs_add_group(net, &netstat_group);
#ifdef CONFIG_WIRELESS_EXT_SYSFS
if (net->ieee80211_ptr)
- *groups++ = &wireless_group;
+ netdev_sysfs_add_group(net, &wireless_group);
#ifdef CONFIG_WIRELESS_EXT
else if (net->wireless_handlers)
- *groups++ = &wireless_group;
+ netdev_sysfs_add_group(net, &wireless_group);
#endif
#endif
#endif /* CONFIG_SYSFS */
^ permalink raw reply related
* Re: [net-next-2.6 PATCH] net: fast consecutive name allocation
From: Ben Greear @ 2009-11-14 16:16 UTC (permalink / raw)
To: Eric Dumazet
Cc: Benny Amorsen, Stephen Hemminger, Benjamin LaHaise,
Octavian Purdila, netdev
In-Reply-To: <4AFE5A6C.2030301@gmail.com>
Eric Dumazet wrote:
> Benny Amorsen a écrit :
>
>> Stephen Hemminger <shemminger@vyatta.com> writes:
>>
>>
>>> Then maybe network devices aren't the right layering model. At some
>>> point the paradigm has to be re-examined.
>>>
>> I'm not quite sure where this becomes a problem. We have 1185 network
>> interfaces (VLAN's) on one box. Boot time is a problem, but other than
>> that it works ok. If something like this would help speed up booting,
>> that would be very nice.
>>
>>
>
> It would be very nice if you tell us why booting is very long,
> ie what is done and how much time it takes.
>
> It's clear that ~1000 vlans is quite reasonable :)
>
At least sometimes, hotplug can degrade into a nasty case where it runs
'ifconfig -a' for each
interface created. (This was F11 if I recall correctly).
If you configure hotplug to ignore vlans, it might help your boot time.
Thanks,
Ben
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [net-next-2.6 PATCH v6 3/7 RFC] TCPCT part 1c: sysctl_tcp_cookie_size, socket option TCP_COOKIE_TRANSACTIONS
From: William Allen Simpson @ 2009-11-14 15:43 UTC (permalink / raw)
To: Joe Perches; +Cc: Linux Kernel Network Developers
In-Reply-To: <4AFDB740.3060509@gmail.com>
William Allen Simpson wrote:
> Joe Perches wrote:
>> or even adding proc_dointvec_minmax_even
>> might save some cycles during cookie handling.
>>
> Well, that would have to be proc_dointvec_minmax_even_zero(), as the
> valid values can be 0, 8, 10, 12, 14, or 16. ...
>
> And it seems to me a case of "premature optimization" -- it might save
> 1 or 2 tests in the order I've listed them in tcp_cookie_size_check(),
> ...
>
> On the server side, we have to test during parsing anyway. I never trust
> any data that comes over the network....
>
I looked at this again today, and proc_dointvec_minmax_even_zero() still
seems to be overkill. I couldn't find anybody else that does such things
at sysctl parsing time.
I did find we could eliminate a test for odd (in part 1f),
+ if (unlikely(0x1 & cookie_size)) {
+ /* 8-bit multiple, illegal, ignore */
+ cookie_size = 0;
by using a better test for the network data (in part 1g), and it
should be faster, too (assuming gcc is smart enough):
Was:
+ if (TCPOLEN_COOKIE_MAX >= opsize
+ && TCPOLEN_COOKIE_MIN <= opsize) {
Now:
+ switch (opsize) {
+ case TCPOLEN_COOKIE_MIN+0:
+ case TCPOLEN_COOKIE_MIN+2:
+ case TCPOLEN_COOKIE_MIN+4:
+ case TCPOLEN_COOKIE_MIN+6:
+ case TCPOLEN_COOKIE_MAX:
(This division into so many parts for review is driving me crazy....)
Saved 2 if's for every cookie! Of course, there's a cpu intensive
SHA1 for each cookie, so this pales in comparison.
Premature optimization or not, thanks for the ideas!
^ permalink raw reply
* Re: [PATCH] ifb: add multi-queue support
From: Changli Gao @ 2009-11-14 13:30 UTC (permalink / raw)
To: Eric Dumazet
Cc: Stephen Hemminger, Jarek Poplawski, David S. Miller,
Patrick McHardy, Tom Herbert, netdev
In-Reply-To: <4AFEA830.3000101@gmail.com>
On Sat, Nov 14, 2009 at 8:53 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Changli Gao a écrit :
>> Yea, the overhead of SoftIRQ is less than kernel threads, and I'll try
>> to find a way to solve both flexibility and efficiency. Maybe I need
>> some real NIC drivers as examples. Is there a standard API to bind RQs
>> of NIC to CPUs, such as ioctl or setsockopt?
>
> Thats a good question... napi is bound to a cpu, and you'll need
> things that were done by Tom Herbert in its RPS patch, to
> be able to deleguate work to remote cpus napi contexts.
>
> But if we consider RPS being close to be committed, shouldnt
> IFB use its, in order to not duplicate changes ?
>
> Or, if you prefer, once RPS is in, we dont need to change IFB, since
> RPS will already split the load to multiple cpus before entering IFB.
>
>
I had known RPS before I began my IFB work, so I added Tom to the CC
list, but I don't know if RPS will be in the mainline. Since there
isn't any core change in IFB as is in RPS, I think it is easier to
merge IFB into the mainline. If RPS is merged before IFB-MQ, I'll give
IFB-MQ up, and vice versa I think.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: linux-next: net tree build failure
From: Arnaldo Carvalho de Melo @ 2009-11-14 13:18 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: David S. Miller, netdev, linux-next, linux-kernel
In-Reply-To: <20091114175041.61bdb27f.sfr@canb.auug.org.au>
Em Sat, Nov 14, 2009 at 05:50:41PM +1100, Stephen Rothwell escreveu:
> Hi Dave,
>
> Today's linux-next build (alpha defconfig) failed like this:
>
> arch/alpha/kernel/systbls.S:507: Error: .err encountered
>
> Caused by commit a2e2725541fad72416326798c2d7fa4dafb7d337 ("net:
> Introduce recvmmsg socket syscall") which added a syscall to the alpha
> syscall table but forgot to update NR_SYSCALLS in
> arch/alpha/include/asm/unistd.h (it also didn't add the __NR_ constant
> thee either).
>
> I suspect that this is true for a few other architectures as well
> (including sparc?).
I'm trying to get hold of a cross compiler setup now...
- Arnaldo
^ permalink raw reply
* Re: [PATCH] ifb: add multi-queue support
From: Eric Dumazet @ 2009-11-14 12:53 UTC (permalink / raw)
To: Changli Gao
Cc: Stephen Hemminger, Jarek Poplawski, David S. Miller,
Patrick McHardy, Tom Herbert, netdev
In-Reply-To: <412e6f7f0911131542w1029893cmd07599660b810ed5@mail.gmail.com>
Changli Gao a écrit :
> Yea, the overhead of SoftIRQ is less than kernel threads, and I'll try
> to find a way to solve both flexibility and efficiency. Maybe I need
> some real NIC drivers as examples. Is there a standard API to bind RQs
> of NIC to CPUs, such as ioctl or setsockopt?
Thats a good question... napi is bound to a cpu, and you'll need
things that were done by Tom Herbert in its RPS patch, to
be able to deleguate work to remote cpus napi contexts.
But if we consider RPS being close to be committed, shouldnt
IFB use its, in order to not duplicate changes ?
Or, if you prefer, once RPS is in, we dont need to change IFB, since
RPS will already split the load to multiple cpus before entering IFB.
^ permalink raw reply
* Re: [PATCH] check the return value of ndo_select_queue()
From: Eric Dumazet @ 2009-11-14 12:37 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, netdev
In-Reply-To: <412e6f7f0911140414x4918d8d2teb60ee585ebdfce9@mail.gmail.com>
Changli Gao a écrit :
>
> It seems better than mime.
>
>
Well, it's still your patch :)
^ permalink raw reply
* Re: [PATCH] check the return value of ndo_select_queue()
From: Changli Gao @ 2009-11-14 12:14 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev
In-Reply-To: <4AFE621C.1020004@gmail.com>
On Sat, Nov 14, 2009 at 3:54 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
> Please always use scripts/checkpatch.pl before sending patches
>
> } else if((select_queue = dev->netdev_ops->ndo_select_queue)) {
>
> A space is required after the "if"
>
Thanks.
> It seems to me this patch is not matching its ChangeLog :
>
> You moved the :
>
> if (sk && sk->sk_dst_cache)
> sk_tx_queue_set(sk, queue_index);
Maybe I did more in my patch, but I think these little changes doesn't
need separate patches.
>
> Why not using much readable patch like :
>
>
> [PATCH] check the return value of ndo_select_queue()
>
> check the return value of ndo_select_queue()
>
> Check the return value of ndo_select_queue(). If the value isn't smaller
> than the real_num_tx_queues, print a warning message, and reset it to zero.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ----
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index ad8e320..bbc9a41 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1845,6 +1845,20 @@ u16 skb_tx_hash(const struct net_device *dev, const struct sk_buff *skb)
> }
> EXPORT_SYMBOL(skb_tx_hash);
>
> +static inline u16 dev_cap_txqueue(struct net_device *dev, u16 queue_index)
> +{
> + if (unlikely(queue_index >= dev->real_num_tx_queues)) {
> + if (net_ratelimit()) {
> + WARN(1, "%s selects TX queue %d, but "
> + "real number of TX queues is %d\n",
> + dev->name, queue_index,
> + dev->real_num_tx_queues);
> + }
> + return 0;
> + }
> + return queue_index;
> +}
> +
> static struct netdev_queue *dev_pick_tx(struct net_device *dev,
> struct sk_buff *skb)
> {
> @@ -1858,6 +1872,7 @@ static struct netdev_queue *dev_pick_tx(struct net_device *dev,
>
> if (ops->ndo_select_queue) {
> queue_index = ops->ndo_select_queue(dev, skb);
> + queue_index = dev_cap_txqueue(dev, queue_index);
> } else {
> queue_index = 0;
> if (dev->real_num_tx_queues > 1)
>
>
>
It seems better than mime.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: TCP throughput drops sharply around MTU of 180 bytes
From: Eric Dumazet @ 2009-11-14 10:19 UTC (permalink / raw)
To: Ang Way Chuang; +Cc: netdev
In-Reply-To: <4AFE7F15.1080504@gmail.com>
Eric Dumazet a écrit :
> Ang Way Chuang a écrit :
>> I assume that ip route .... advmss achieves that effect? I tried it,
>> but it doesn't work.
>>
>
> It should. Please provide your kernel version and what you tried exactly.
>
>
Here a tcpdump of an iperf -M 120 session on current net-next-2.6 kernel
iperf -M 120 -c 192.168.0.1 -m
WARNING: attempt to set TCP maximum segment size to 120, but got 536
------------------------------------------------------------
Client connecting to 192.168.0.1, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.2 port 48178 connected with 192.168.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 26.4 MBytes 22.1 Mbits/sec
[ 3] MSS size 108 bytes (MTU 148 bytes, unknown interface)
hints :
1) Use iperf -M 120 flag on both sides
2) disable tso/gso on sender
ethtool -K eth0 tso off gso off
11:15:17.052202 IP 192.168.0.2.48177 > 192.168.0.1.5001: S 3914872183:3914872183(0) win 480 <mss 120,nop,nop,timestamp 63768988 0,nop,wscale 6>
11:15:17.052291 IP 192.168.0.1.5001 > 192.168.0.2.48177: S 2771326659:2771326659(0) ack 3914872184 win 432 <mss 120,nop,nop,timestamp 580923920 63768988,nop,wscale 6>
11:15:17.052494 IP 192.168.0.2.48177 > 192.168.0.1.5001: . ack 1 win 8 <nop,nop,timestamp 63768988 580923920>
11:15:17.052514 IP 192.168.0.2.48177 > 192.168.0.1.5001: P 1:25(24) ack 1 win 8 <nop,nop,timestamp 63768988 580923920>
11:15:17.052532 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 25:133(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923920>
11:15:17.052534 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 133:241(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923920>
11:15:17.052537 IP 192.168.0.2.48177 > 192.168.0.1.5001: P 241:349(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923920>
11:15:17.052612 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 25 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.052621 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 349:457(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052624 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 133 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.052629 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 457:565(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052631 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 349 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.052635 IP 192.168.0.2.48177 > 192.168.0.1.5001: P 565:673(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052638 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 673:781(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052711 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 565 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.052715 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 781:889(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052718 IP 192.168.0.2.48177 > 192.168.0.1.5001: P 889:997(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052720 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 781 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.052724 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 997:1105(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052727 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 1105:1213(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052804 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 997 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.052813 IP 192.168.0.2.48177 > 192.168.0.1.5001: P 1213:1321(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052816 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 1321:1429(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052823 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 1213 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.052827 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 1429:1537(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052829 IP 192.168.0.2.48177 > 192.168.0.1.5001: P 1537:1645(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052901 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 1429 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.052910 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 1645:1753(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052913 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 1753:1861(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052914 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 1645 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.052917 IP 192.168.0.2.48177 > 192.168.0.1.5001: P 1861:1969(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052920 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 1969:2077(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052990 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 1861 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.052996 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 2077:2185(108) ack 1 win 8 <nop,nop,timestamp 63768989 580923921>
11:15:17.052999 IP 192.168.0.2.48177 > 192.168.0.1.5001: P 2185:2293(108) ack 1 win 8 <nop,nop,timestamp 63768989 580923921>
11:15:17.053001 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 2077 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.053005 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 2293:2401(108) ack 1 win 8 <nop,nop,timestamp 63768989 580923921>
11:15:17.053008 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 2401:2509(108) ack 1 win 8 <nop,nop,timestamp 63768989 580923921>
^ permalink raw reply
* Re: TCP throughput drops sharply around MTU of 180 bytes
From: Eric Dumazet @ 2009-11-14 9:57 UTC (permalink / raw)
To: Ang Way Chuang; +Cc: netdev
In-Reply-To: <51d384e10911140124g285621a5n54afa1bdb1b02997@mail.gmail.com>
Ang Way Chuang a écrit :
> I assume that ip route .... advmss achieves that effect? I tried it,
> but it doesn't work.
>
It should. Please provide your kernel version and what you tried exactly.
^ permalink raw reply
* Re: TCP throughput drops sharply around MTU of 180 bytes
From: Ang Way Chuang @ 2009-11-14 9:24 UTC (permalink / raw)
To: Eric Dumazet, netdev
In-Reply-To: <4AFE748C.3050100@gmail.com>
I assume that ip route .... advmss achieves that effect? I tried it,
but it doesn't work.
On Sat, Nov 14, 2009 at 5:12 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Eric Dumazet a écrit :
>>
>> Oh well, this reminds me TCP_MAXSEG doesnt work as expected...
>
> Oops, this problem I had few years ago was fixed last year in 2.6.27, sorry ...
>
> commit f5fff5dc8a7a3f395b0525c02ba92c95d42b7390
> Author: Tom Quetchenbach <virtualphtn@gmail.com>
> Date: Sun Sep 21 00:21:51 2008 -0700
>
> tcp: advertise MSS requested by user
>
> I'm trying to use the TCP_MAXSEG option to setsockopt() to set the MSS
> for both sides of a bidirectional connection.
>
> man tcp says: "If this option is set before connection establishment, it
> also changes the MSS value announced to the other end in the initial
> packet."
>
> However, the kernel only uses the MTU/route cache to set the advertised
> MSS. That means if I set the MSS to, say, 500 before calling connect(),
> I will send at most 500-byte packets, but I will still receive 1500-byte
> packets in reply.
>
> This is a bug, either in the kernel or the documentation.
>
> This patch (applies to latest net-2.6) reduces the advertised value to
> that requested by the user as long as setsockopt() is called before
> connect() or accept(). This seems like the behavior that one would
> expect as well as that which is documented.
>
> I've tried to make sure that things that depend on the advertised MSS
> are set correctly.
>
> Signed-off-by: Tom Quetchenbach <virtualphtn@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
>
>
>
^ permalink raw reply
* Re: TCP throughput drops sharply around MTU of 180 bytes
From: Eric Dumazet @ 2009-11-14 9:12 UTC (permalink / raw)
To: Ang Way Chuang; +Cc: netdev
In-Reply-To: <4AFE6FF0.3030101@gmail.com>
Eric Dumazet a écrit :
>
> Oh well, this reminds me TCP_MAXSEG doesnt work as expected...
Oops, this problem I had few years ago was fixed last year in 2.6.27, sorry ...
commit f5fff5dc8a7a3f395b0525c02ba92c95d42b7390
Author: Tom Quetchenbach <virtualphtn@gmail.com>
Date: Sun Sep 21 00:21:51 2008 -0700
tcp: advertise MSS requested by user
I'm trying to use the TCP_MAXSEG option to setsockopt() to set the MSS
for both sides of a bidirectional connection.
man tcp says: "If this option is set before connection establishment, it
also changes the MSS value announced to the other end in the initial
packet."
However, the kernel only uses the MTU/route cache to set the advertised
MSS. That means if I set the MSS to, say, 500 before calling connect(),
I will send at most 500-byte packets, but I will still receive 1500-byte
packets in reply.
This is a bug, either in the kernel or the documentation.
This patch (applies to latest net-2.6) reduces the advertised value to
that requested by the user as long as setsockopt() is called before
connect() or accept(). This seems like the behavior that one would
expect as well as that which is documented.
I've tried to make sure that things that depend on the advertised MSS
are set correctly.
Signed-off-by: Tom Quetchenbach <virtualphtn@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: TCP throughput drops sharply around MTU of 180 bytes
From: Eric Dumazet @ 2009-11-14 8:53 UTC (permalink / raw)
To: Ang Way Chuang; +Cc: netdev
In-Reply-To: <51d384e10911140028r76e1aefei3a224b5c542d82e8@mail.gmail.com>
Ang Way Chuang a écrit :
> Hi kernel networking gurus,
>
> I came across a situation where I need to evaluate the packing
> efficiency of
> small packets. Because TCP is byte oriented protocol, there is no way
> to force it
> to generate small packets, so I forced it by adjusting MTU.
>
> However, through the experiment, I found that measured throughput
> of TCP stream dropped significantly if MTU is set to value less than 180 bytes.
> At first, I thought it must be some bugs on my code. So, I decided to repeat
> the test over a dedicated 10Mbps Ethernet link. The results that I measured
> over Ethernet is shown below:
>
>
> MTU Throughput (Mbps)
> ----- --------------
> 181 4.50
> 180 4.39
> 179 3.05
> 178 3.04
>
> I used iperf throughout the tests. Can someone enlighten me on this matter?
> Why the throughput drops sharply if MTU is less than 180 bytes? Is there some
> special meaning associated with 180 that I don't know of?
>
> Some basic information about my system:
> kernel version: 2.6.27.5-117.fc10.x86_64
> distro: fedora 10
> CPU: Pentium 4 3.00 GHz
>
> Should you need more information, I shall gladly cooperate. Please keep me
> in the loop because it is hard for me to cop with the volume of emails on netdev
> mailing list.
>
Oh well, this reminds me TCP_MAXSEG doesnt work as expected...
^ permalink raw reply
* TCP throughput drops sharply around MTU of 180 bytes
From: Ang Way Chuang @ 2009-11-14 8:48 UTC (permalink / raw)
To: netdev
Hi kernel networking gurus,
I came across a situation where I need to evaluate the packing
efficiency of small packets. Because TCP is byte oriented protocol,
there is no way
to force it to generate small packets, so I forced it by adjusting MTU.
However, through the experiment, I found that measured throughput
of TCP stream dropped significantly if MTU is set to value less than 180 bytes.
At first, I thought it must be some bugs on my code. So, I decided to repeat
the test over a dedicated 10Mbps Ethernet link. The results that I measured
over Ethernet is shown below:
MTU Throughput (Mbps)
----- --------------
181 4.50
180 4.39
179 3.05
178 3.04
I used iperf throughout the tests. Can someone enlighten me on this matter?
Why the throughput drops sharply if MTU is less than 180 bytes? Is there some
special meaning associated with 180 that I don't know of?
Some basic information about my system:
kernel version: 2.6.27.5-117.fc10.x86_64
distro: fedora 10
CPU: Pentium 4 3.00 GHz
Should you need more information, I shall gladly cooperate. Please keep me
in the loop because it is hard for me to cop with the volume of emails on netdev
mailing list.
Thank you in advance.
Regards,
Ang Way Chuang
^ permalink raw reply
* [PATCH] forcedeth: mac address fix
From: Stanislav O. Bezzubtsev @ 2009-11-14 8:31 UTC (permalink / raw)
Cc: davem, aabdulla, yinghai, netdev, linux-kernel,
Stanislav O. Bezzubtsev
Use the existing random_ether_addr() to generate random MAC
instead of doing it by-hand.
Signed-off-by: Stanislav O. Bezzubtsev <stas@lvk.cs.msu.su>
---
drivers/net/forcedeth.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index e1da466..3116601 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -5821,10 +5821,7 @@ static int __devinit nv_probe(struct pci_dev *pci_dev, const struct pci_device_i
dev->dev_addr);
dev_printk(KERN_ERR, &pci_dev->dev,
"Please complain to your hardware vendor. Switching to a random MAC.\n");
- dev->dev_addr[0] = 0x00;
- dev->dev_addr[1] = 0x00;
- dev->dev_addr[2] = 0x6c;
- get_random_bytes(&dev->dev_addr[3], 3);
+ random_ether_addr(dev->dev_addr);
}
dprintk(KERN_DEBUG "%s: MAC Address %pM\n",
--
1.6.5
^ permalink raw reply related
* TCP throughput drops sharply around MTU of 180 bytes
From: Ang Way Chuang @ 2009-11-14 8:28 UTC (permalink / raw)
To: netdev
Hi kernel networking gurus,
I came across a situation where I need to evaluate the packing
efficiency of
small packets. Because TCP is byte oriented protocol, there is no way
to force it
to generate small packets, so I forced it by adjusting MTU.
However, through the experiment, I found that measured throughput
of TCP stream dropped significantly if MTU is set to value less than 180 bytes.
At first, I thought it must be some bugs on my code. So, I decided to repeat
the test over a dedicated 10Mbps Ethernet link. The results that I measured
over Ethernet is shown below:
MTU Throughput (Mbps)
----- --------------
181 4.50
180 4.39
179 3.05
178 3.04
I used iperf throughout the tests. Can someone enlighten me on this matter?
Why the throughput drops sharply if MTU is less than 180 bytes? Is there some
special meaning associated with 180 that I don't know of?
Some basic information about my system:
kernel version: 2.6.27.5-117.fc10.x86_64
distro: fedora 10
CPU: Pentium 4 3.00 GHz
Should you need more information, I shall gladly cooperate. Please keep me
in the loop because it is hard for me to cop with the volume of emails on netdev
mailing list.
Thank you in advance.
Regards,
Ang Way Chuang
^ permalink raw reply
* Re: [rfc 0/4] igb: bandwidth allocation
From: Jeff Kirsher @ 2009-11-14 8:01 UTC (permalink / raw)
To: Simon Horman; +Cc: e1000-devel, netdev, Arnd Bergmann
In-Reply-To: <20091105022123.GA22019@verge.net.au>
On Wed, Nov 4, 2009 at 18:21, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Nov 04, 2009 at 05:46:50PM -0800, Jeff Kirsher wrote:
>> On Wed, Nov 4, 2009 at 16:58, Simon Horman <horms@verge.net.au> wrote:
>> > Hi,
>> >
>> > this series of patches exposes the bandwidth allocation
>> > hardware support of the Intel 82576. It does so through
>> > a rather hackish sysfs entry. That interface is just intended
>> > for testing so that the exposed hardware feature can
>> > be exercised. I would like to find a generic way to expose
>> > this feature to user-space.
>> >
>>
>> Thanks Simon. I have add the 4 patch series to my tree for testing.
>
> Thanks. I wanted to get the code out rather than sitting on it
> for lack of a better user-space interface. Although there
> is a lot of fluff the actual register twiddling for
> bandwidth allocation turned out to be quite simple.
>
Simon -
After doing some testing on the series of patches, we are getting a
panic with these patches applied to net-next. I have provided below
the panic we saw, right now we have a large patch load so a bisect
will have to wait. Hopefully with time permitting, we will be able to
revisit these patches soon.
igbvf 0000:02:10.0: PF still resetting
igbvf 0000:02:10.2: PF still resetting
igbvf 0000:02:10.4: PF still resetting
igbvf 0000:02:10.6: PF still resetting
igbvf 0000:02:11.0: PF still resetting
igbvf 0000:02:11.2: PF still resetting
igbvf 0000:02:11.4: PF still resetting
igbvf 0000:02:10.1: PF still resetting
igbvf 0000:02:10.3: PF still resetting
igbvf 0000:02:10.5: PF still resetting
igbvf 0000:02:10.7: PF still resetting
igbvf 0000:02:11.1: PF still resetting
igbvf 0000:02:11.3: PF still resetting
igbvf 0000:02:11.5: PF still resetting
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: [<ffffffffa0087d3c>] igb_xmit_frame_ring_adv+0x1d/0x71a [igb] PGD 0
Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC last sysfs file:
/sys/bus/pci/slots/1-1/address CPU 1 Modules linked in: igbvf igb ipv6
autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table video output
sbs sbshc joydev e1000e e1000 i2c_i801 shpchp i2c_core pcspkr iTCO_wdt
iTCO_vendor_support usb_storage [last unloaded: igb]
Pid: 52, comm: events/1 Not tainted 2.6.32-rc3-net-next-vf-tag111109 #1 S5520HC
RIP: 0010:[<ffffffffa0087d3c>] [<ffffffffa0087d3c>]
igb_xmit_frame_ring_adv+0x1d/0x71a [igb]
RSP: 0018:ffff8801f8803aa0 EFLAGS: 00010286
RAX: 0000000000000001 RBX: 0000000000000600 RCX: 0000000000000000
RDX: ffff8803609e4700 RSI: 0000000000000000 RDI: ffff88036559d500
RBP: ffff8801f8803b10 R08: 0000000000000000 R09: ffff8801f8994018
R10: ffff88036559d500 R11: ffffffff81e9caf8 R12: ffff88036559d500
R13: ffff88036559d500 R14: 0000000000000000 R15: ffff88036791a4c0
FS: 0000000000000000(0000) GS:ffff8801f8800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000008 CR3: 0000000001001000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process events/1 (pid: 52, threadinfo ffff8801e91a6000, task
ffff8801e91abfc0)
Stack:
ffff8801e91abfc0 0000000000000000 0000000000000001 0000000000000000
<0> ffff8801f8803b20 0000000000000246 0000000000000000
ffffffff812f7558 <0> ffff880100000000 ffff8803609f4e00
ffff88036559d500 ffff8803609e4000 Call Trace:
<IRQ>
[<ffffffff812f7558>] ? __netif_tx_lock+0x16/0x1f
[<ffffffffa008c130>] igb_xmit_frame_adv+0x3a/0x3c [igb]
[<ffffffff812e55d7>] dev_hard_start_xmit+0x1d1/0x27e
[<ffffffff812f7cc2>] sch_direct_xmit+0x68/0x14e [<ffffffff812e59bd>]
dev_queue_xmit+0x22e/0x378 [<ffffffff812e588d>] ?
dev_queue_xmit+0xfe/0x378 [<ffffffff8104b565>] ?
_local_bh_enable_ip+0x9c/0xa7 [<ffffffff812eb72c>]
neigh_resolve_output+0x1f0/0x225 [<ffffffffa013a3be>]
ip6_output_finish+0x6f/0xd6 [ipv6] [<ffffffffa013adbb>]
ip6_output2+0x328/0x337 [ipv6] [<ffffffffa013bcce>]
ip6_output+0xf04/0xf28 [ipv6] [<ffffffffa01547af>] dst_output+0xb/0xd
[ipv6] [<ffffffffa0155ea7>] mld_sendpack+0x2aa/0x48f [ipv6]
[<ffffffffa0157001>] mld_ifc_timer_expire+0x1c8/0x201 [ipv6]
[<ffffffffa0156e39>] ? mld_ifc_timer_expire+0x0/0x201 [ipv6]
[<ffffffff81051667>] run_timer_softirq+0x1b0/0x26b
[<ffffffff810515da>] ? run_timer_softirq+0x123/0x26b
[<ffffffff8106681b>] ? ktime_get+0x73/0x8e [<ffffffff8106a79e>] ?
tick_dev_program_event+0x2a/0x9c [<ffffffff8104bcf1>]
__do_softirq+0xd5/0x19d [<ffffffff8100cc9c>] call_softirq+0x1c/0x34
[<ffffffff8100e2d8>] do_softirq+0x33/0x6b [<ffffffff8104b959>]
irq_exit+0x36/0x8a [<ffffffff81020129>]
smp_apic_timer_interrupt+0x78/0x87
[<ffffffff8100c673>] apic_timer_interrupt+0x13/0x20 <EOI>
[<ffffffff8130dec4>] ? rt_cache_flush+0x154/0x169
[<ffffffff8133feeb>] ? fib_netdev_event+0x84/0x8b
[<ffffffff81382b1c>] ? notifier_call_chain+0x33/0x5b
[<ffffffff812f0fd5>] ? linkwatch_event+0x0/0x31 [<ffffffff81062679>]
? __raw_notifier_call_chain+0x9/0xb [<ffffffff8106268a>] ?
raw_notifier_call_chain+0xf/0x11 [<ffffffff812e5b9d>] ?
call_netdevice_notifiers+0x16/0x18
--
Cheers,
Jeff
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
^ permalink raw reply
* Re: [PATCH] check the return value of ndo_select_queue()
From: Eric Dumazet @ 2009-11-14 7:54 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, netdev
In-Reply-To: <412e6f7f0911131650j6d13f95bt20aa607f9f44c3af@mail.gmail.com>
Changli Gao a écrit :
> check the return value of ndo_select_queue()
>
> Check the return value of ndo_select_queue(). If the value isn't smaller
> than the real_num_tx_queues, print a warning message, and reset it to zero.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> ----
> net/core/dev.c | 33 ++++++++++++++++++++++++---------
> 1 file changed, 24 insertions(+), 9 deletions(-)
> diff --git a/net/core/dev.c b/net/core/dev.c
> index bf629ac..74a3824 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1849,22 +1849,37 @@ static struct netdev_queue *dev_pick_tx(struct
> net_device *dev,
> {
> u16 queue_index;
> struct sock *sk = skb->sk;
> + unsigned int real_num_tx_queues = dev->real_num_tx_queues;
>
> if (sk_tx_queue_recorded(sk)) {
> queue_index = sk_tx_queue_get(sk);
> + if (unlikely(queue_index >= real_num_tx_queues)) {
> + do {
> + queue_index -= real_num_tx_queues;
> + } while (queue_index >= real_num_tx_queues);
> + sk_tx_queue_set(sk, queue_index);
> + }
> } else {
> - const struct net_device_ops *ops = dev->netdev_ops;
> + u16 (*select_queue)(struct net_device *, struct sk_buff *);
>
> - if (ops->ndo_select_queue) {
> - queue_index = ops->ndo_select_queue(dev, skb);
> - } else {
> + if (real_num_tx_queues == 1) {
> queue_index = 0;
> - if (dev->real_num_tx_queues > 1)
> - queue_index = skb_tx_hash(dev, skb);
> -
> - if (sk && sk->sk_dst_cache)
> - sk_tx_queue_set(sk, queue_index);
> + } else if((select_queue = dev->netdev_ops->ndo_select_queue)) {
> + queue_index = select_queue(dev, skb);
> + if (unlikely(queue_index >= real_num_tx_queues)) {
> + if (net_ratelimit())
> + WARN(1, "%s selects TX queue %d, but "
> + "real number of TX queues is %d\n",
> + dev->name, queue_index,
> + real_num_tx_queues);
> + queue_index = 0;
> + }
> + } else {
> + queue_index = skb_tx_hash(dev, skb);
> }
> +
> + if (sk && sk->sk_dst_cache)
> + sk_tx_queue_set(sk, queue_index);
> }
>
> skb_set_queue_mapping(skb, queue_index);
Please always use scripts/checkpatch.pl before sending patches
} else if((select_queue = dev->netdev_ops->ndo_select_queue)) {
A space is required after the "if"
It seems to me this patch is not matching its ChangeLog :
You moved the :
if (sk && sk->sk_dst_cache)
sk_tx_queue_set(sk, queue_index);
Why not using much readable patch like :
[PATCH] check the return value of ndo_select_queue()
check the return value of ndo_select_queue()
Check the return value of ndo_select_queue(). If the value isn't smaller
than the real_num_tx_queues, print a warning message, and reset it to zero.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
----
diff --git a/net/core/dev.c b/net/core/dev.c
index ad8e320..bbc9a41 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1845,6 +1845,20 @@ u16 skb_tx_hash(const struct net_device *dev, const struct sk_buff *skb)
}
EXPORT_SYMBOL(skb_tx_hash);
+static inline u16 dev_cap_txqueue(struct net_device *dev, u16 queue_index)
+{
+ if (unlikely(queue_index >= dev->real_num_tx_queues)) {
+ if (net_ratelimit()) {
+ WARN(1, "%s selects TX queue %d, but "
+ "real number of TX queues is %d\n",
+ dev->name, queue_index,
+ dev->real_num_tx_queues);
+ }
+ return 0;
+ }
+ return queue_index;
+}
+
static struct netdev_queue *dev_pick_tx(struct net_device *dev,
struct sk_buff *skb)
{
@@ -1858,6 +1872,7 @@ static struct netdev_queue *dev_pick_tx(struct net_device *dev,
if (ops->ndo_select_queue) {
queue_index = ops->ndo_select_queue(dev, skb);
+ queue_index = dev_cap_txqueue(dev, queue_index);
} else {
queue_index = 0;
if (dev->real_num_tx_queues > 1)
^ permalink raw reply related
* Re: [RFC] vlan: GRO rx statistics
From: Eric Dumazet @ 2009-11-14 7:27 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <20091114012741.GA18764@gondor.apana.org.au>
Herbert Xu a écrit :
> On Fri, Nov 13, 2009 at 05:41:21PM +0100, Eric Dumazet wrote:
>> Replying to myself, I found root of the problem and posted a fix.
>
> Just curious, do you have a link to that fix?
>
Sure, I thought you were a netdev subscriber, sorry :)
[PATCH net-next-2.6] vlan: Use __vlan_hwaccel_put_tag() in rx
http://patchwork.ozlabs.org/patch/38377/
>> Still the race while updating dev->stats.tx_{bytes|packets} should be addressed eventually...
>
> Well making it per-napi_struct should do the trick.
>
> Cheers,
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net: fast consecutive name allocation
From: Eric Dumazet @ 2009-11-14 7:21 UTC (permalink / raw)
To: Benny Amorsen
Cc: Stephen Hemminger, Benjamin LaHaise, Octavian Purdila, netdev
In-Reply-To: <m3r5s1bn3f.fsf@ursa.amorsen.dk>
Benny Amorsen a écrit :
> Stephen Hemminger <shemminger@vyatta.com> writes:
>
>> Then maybe network devices aren't the right layering model. At some
>> point the paradigm has to be re-examined.
>
> I'm not quite sure where this becomes a problem. We have 1185 network
> interfaces (VLAN's) on one box. Boot time is a problem, but other than
> that it works ok. If something like this would help speed up booting,
> that would be very nice.
>
It would be very nice if you tell us why booting is very long,
ie what is done and how much time it takes.
It's clear that ~1000 vlans is quite reasonable :)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox