* [PATCH net-next] net: Optimize hard_start_xmit() return checking
From: Jarek Poplawski @ 2009-11-15 17:20 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List, Patrick McHardy
Recent changes in the TX error propagation require additional checking
and masking of values returned from hard_start_xmit(), mainly to
separate cases where skb was consumed. This aim can be simplified by
changing the order of NETDEV_TX and NET_XMIT codes, because the latter
are treated similarly to negative (ERRNO) values.
After this change much simpler dev_xmit_complete() is also used in
sch_direct_xmit(), so it is moved to netdevice.h.
Additionally NET_RX definitions in netdevice.h are moved up from
between TX codes to avoid confusion while reading the TX comment.
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
---
include/linux/netdevice.h | 42 ++++++++++++++++++++++++++++++------------
net/core/dev.c | 17 -----------------
net/sched/sch_generic.c | 23 +++++------------------
3 files changed, 35 insertions(+), 47 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 61425d0..7043f85 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -63,6 +63,10 @@ struct wireless_dev;
#define HAVE_FREE_NETDEV /* free_netdev() */
#define HAVE_NETDEV_PRIV /* netdev_priv() */
+/* Backlog congestion levels */
+#define NET_RX_SUCCESS 0 /* keep 'em coming, baby */
+#define NET_RX_DROP 1 /* packet dropped */
+
/*
* Transmit return codes: transmit return codes originate from three different
* namespaces:
@@ -82,14 +86,10 @@ struct wireless_dev;
/* qdisc ->enqueue() return codes. */
#define NET_XMIT_SUCCESS 0x00
-#define NET_XMIT_DROP 0x10 /* skb dropped */
-#define NET_XMIT_CN 0x20 /* congestion notification */
-#define NET_XMIT_POLICED 0x30 /* skb is shot by police */
-#define NET_XMIT_MASK 0xf0 /* qdisc flags in net/sch_generic.h */
-
-/* Backlog congestion levels */
-#define NET_RX_SUCCESS 0 /* keep 'em coming, baby */
-#define NET_RX_DROP 1 /* packet dropped */
+#define NET_XMIT_DROP 0x01 /* skb dropped */
+#define NET_XMIT_CN 0x02 /* congestion notification */
+#define NET_XMIT_POLICED 0x03 /* skb is shot by police */
+#define NET_XMIT_MASK 0x0f /* qdisc flags in net/sch_generic.h */
/* NET_XMIT_CN is special. It does not guarantee that this packet is lost. It
* indicates that the device will soon be dropping packets, or already drops
@@ -98,16 +98,34 @@ struct wireless_dev;
#define net_xmit_errno(e) ((e) != NET_XMIT_CN ? -ENOBUFS : 0)
/* Driver transmit return codes */
-#define NETDEV_TX_MASK 0xf
+#define NETDEV_TX_MASK 0xf0
enum netdev_tx {
__NETDEV_TX_MIN = INT_MIN, /* make sure enum is signed */
- NETDEV_TX_OK = 0, /* driver took care of packet */
- NETDEV_TX_BUSY = 1, /* driver tx path was busy*/
- NETDEV_TX_LOCKED = 2, /* driver tx lock was already taken */
+ NETDEV_TX_OK = 0x00, /* driver took care of packet */
+ NETDEV_TX_BUSY = 0x10, /* driver tx path was busy*/
+ NETDEV_TX_LOCKED = 0x20, /* driver tx lock was already taken */
};
typedef enum netdev_tx netdev_tx_t;
+/*
+ * Current order: NETDEV_TX_MASK > NET_XMIT_MASK >= 0 is significant;
+ * hard_start_xmit() return < NET_XMIT_MASK means skb was consumed.
+ */
+static inline bool dev_xmit_complete(int rc)
+{
+ /*
+ * Positive cases with an skb consumed by a driver:
+ * - successful transmission (rc == NETDEV_TX_OK)
+ * - error while transmitting (rc < 0)
+ * - error while queueing to a different device (rc & NET_XMIT_MASK)
+ */
+ if (likely(rc < NET_XMIT_MASK))
+ return true;
+
+ return false;
+}
+
#endif
#define MAX_ADDR_LEN 32 /* Largest hardware address length */
diff --git a/net/core/dev.c b/net/core/dev.c
index 548340b..67669c4 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1909,23 +1909,6 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
return rc;
}
-static inline bool dev_xmit_complete(int rc)
-{
- /* successful transmission */
- if (rc == NETDEV_TX_OK)
- return true;
-
- /* error while transmitting, driver consumed skb */
- if (rc < 0)
- return true;
-
- /* error while queueing to a different device, driver consumed skb */
- if (rc & NET_XMIT_MASK)
- return true;
-
- return false;
-}
-
/**
* dev_queue_xmit - transmit a buffer
* @skb: buffer to transmit
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index b13821a..5173c1e 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -119,39 +119,26 @@ int sch_direct_xmit(struct sk_buff *skb, struct Qdisc *q,
spin_unlock(root_lock);
HARD_TX_LOCK(dev, txq, smp_processor_id());
- if (!netif_tx_queue_stopped(txq) &&
- !netif_tx_queue_frozen(txq)) {
+ if (!netif_tx_queue_stopped(txq) && !netif_tx_queue_frozen(txq))
ret = dev_hard_start_xmit(skb, dev, txq);
- /* an error implies that the skb was consumed */
- if (ret < 0)
- ret = NETDEV_TX_OK;
- /* all NET_XMIT codes map to NETDEV_TX_OK */
- ret &= ~NET_XMIT_MASK;
- }
HARD_TX_UNLOCK(dev, txq);
spin_lock(root_lock);
- switch (ret) {
- case NETDEV_TX_OK:
- /* Driver sent out skb successfully */
+ if (dev_xmit_complete(ret)) {
+ /* Driver sent out skb successfully or skb was consumed */
ret = qdisc_qlen(q);
- break;
-
- case NETDEV_TX_LOCKED:
+ } else if (ret == NETDEV_TX_LOCKED) {
/* Driver try lock failed */
ret = handle_dev_cpu_collision(skb, txq, q);
- break;
-
- default:
+ } else {
/* Driver returned NETDEV_TX_BUSY - requeue skb */
if (unlikely (ret != NETDEV_TX_BUSY && net_ratelimit()))
printk(KERN_WARNING "BUG %s code %d qlen %d\n",
dev->name, ret, q->q.qlen);
ret = dev_requeue_skb(skb, q);
- break;
}
if (ret && (netif_tx_queue_stopped(txq) ||
^ permalink raw reply related
* Re: [net-next-2.6 PATCH] net: fast consecutive name allocation
From: Benjamin LaHaise @ 2009-11-15 16:50 UTC (permalink / raw)
To: Denys Fedoryschenko
Cc: Mark Smith, David Miller, shemminger, opurdila, eric.dumazet,
netdev
In-Reply-To: <200911150355.15204.denys@visp.net.lb>
Hi Denys,
On Sun, Nov 15, 2009 at 03:55:14AM +0200, Denys Fedoryschenko wrote:
> And interface creation speed is important for me, when electricity goes down
> here, many customers disconnects (up to 500 on single NAS), and then join
> again to NAS. Load average was jumping to sky on such situations, just option
> to not create sysfs entries helped me a lot (was posted recently).
> Electricity outage is usual here, happens 2-3 times daily.
This is exactly the type of scenario I'm looking at. The design of the
Babylon PPP stack is meant to scale somewhat better that pppd. It uses a
single process (although I'm starting to add threads to improve scaling on
SMP systems) for all PPP/L2TP sessions, and has rather lower connection
setup overhead (no fork()/exec() being the biggest one). With udev tuned,
irqbalance disabled and a few other tweaks, it gets >500 connections per
second in startup on a modern 2.6GHz processor for L2TP traffic. There
is PPPoE support, but it needs a bit more work done to scale automatically
(there are a few hardcoded limits in the PPPoE implementation).
-ben
^ permalink raw reply
* Re: Phonet userspace bits?
From: Rémi Denis-Courmont @ 2009-11-15 16:31 UTC (permalink / raw)
To: dag; +Cc: netdev
In-Reply-To: <1272976626.71600.1258301725789.JavaMail.mail@webmail06>
Hello,
Le dimanche 15 novembre 2009 18:15:25 dag@bakke.com, vous avez écrit :
> How do an end-user make use of a phonet network interface?
>
> Nov 15 16:31:54 toshr500 usb 1-1: New USB device found, idVendor=0421,
> idProduct=046e Nov 15 16:31:54 toshr500 usb 1-1: New USB device strings:
> Mfr=1, Product=2, SerialNumber=0 Nov 15 16:31:54 toshr500 usb 1-1:
> Product: Nokia 6110 Navigator
> Nov 15 16:31:54 toshr500 usb 1-1: Manufacturer: Nokia
> Nov 15 16:31:54 toshr500 usb 1-1: configuration #1 chosen from 1 choice
> Nov 15 16:31:54 toshr500 cdc_acm 1-1:1.8: ttyACM0: USB ACM device
>
> So I can use /dev/ttyACM0 with pppd and get a 3G connection. so far, so
> good.
>
> But what is the usbpn0 network interface, and could I use that instead of
> fiddling with chatscripts and pppd, to get a 3G connection? Is this
> feature complete?
Just like with PPP, only the Phonet data path is implemented in kernel. The
setup is done in userspace. In theory, it could be done in kernelspace too,
but there was strong reluctance against this on usb-devel. And well, maybe we
don't want to taint the kernel with too much of the GPRS specifics.
There was a preliminary patch adding the userspace bits to oFono here:
http://lists.ofono.org/pipermail/ofono/2009-September/000376.html
(especially part 0003) but this is still work in progress.
Best regards,
--
Rémi Denis-Courmont
http://www.remlab.net/
^ permalink raw reply
* Phonet userspace bits?
From: dag @ 2009-11-15 16:15 UTC (permalink / raw)
To: netdev
In-Reply-To: <!256485B18-474275-V2@support.norwegian.no>
Hi.
How do an end-user make use of a phonet network interface?
Nov 15 16:31:54 toshr500 usb 1-1: New USB device found, idVendor=0421, idProduct=046e
Nov 15 16:31:54 toshr500 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Nov 15 16:31:54 toshr500 usb 1-1: Product: Nokia 6110 Navigator
Nov 15 16:31:54 toshr500 usb 1-1: Manufacturer: Nokia
Nov 15 16:31:54 toshr500 usb 1-1: configuration #1 chosen from 1 choice
Nov 15 16:31:54 toshr500 cdc_acm 1-1:1.8: ttyACM0: USB ACM device
So I can use /dev/ttyACM0 with pppd and get a 3G connection. so far, so good.
But what is the usbpn0 network interface, and could I use that instead of fiddling with chatscripts and pppd, to get a 3G connection?
Is this feature complete?
Google came up short on this topic, and the kernel documentation did not enlighten me.
The best I find is http://kerneltrap.org/mailarchive/linux-usb/2009/7/21/6243913 .
Does this still describe the current state of affairs?
Thanks,
Dag B
^ permalink raw reply
* [PATCH net-next-2.6] r6040: fix version printing
From: Florian Fainelli @ 2009-11-15 13:49 UTC (permalink / raw)
To: netdev; +Cc: David Miller
The version string already contains the printk level
specifying it again results in the following message
being printed:
<6>r6040: RDC R6040 NAPI ...
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c
index 7dfcb58..8b14c6e 100644
--- a/drivers/net/r6040.c
+++ b/drivers/net/r6040.c
@@ -1085,7 +1085,7 @@ static int __devinit r6040_init_one(struct pci_dev *pdev,
int bar = 0;
u16 *adrp;
- printk(KERN_INFO "%s\n", version);
+ printk("%s\n", version);
err = pci_enable_device(pdev);
if (err)
^ permalink raw reply related
* Re: [PATCH] can: add the missing netlink get_xstats_size callback
From: Wolfgang Grandegger @ 2009-11-15 11:58 UTC (permalink / raw)
To: David Miller
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20091113.195824.48418352.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller wrote:
> From: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
> Date: Thu, 12 Nov 2009 16:34:05 +0100
>
>> This patch adds the missing "get_xstats_size" callback for the
>> netlink interface, which is required if "fill_xstats" is used,
>> as pointed out by Patrick McHardy.
>>
>> Signed-off-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
>
> Applied.
It would make sense to apply this patch to net-2.6 as well.
Wolfgang.
^ permalink raw reply
* Re: [PATCH] net/can: add driver for mscan family & mpc52xx_mscan
From: Wolfgang Grandegger @ 2009-11-15 11:55 UTC (permalink / raw)
To: David Miller
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ,
linuxppc-dev-mnsaURCQ41sdnm+yROfE0A
In-Reply-To: <20091113.205138.168699769.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller wrote:
> From: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Date: Fri, 13 Nov 2009 17:14:52 +0100
>
>> Taken from socketcan-svn, fixed remaining todos, cleaned up, tested with a
>> phyCORE-MPC5200B-IO and a custom board.
>>
>> Signed-off-by: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>
> Applied.
Unfortunately too early. I will send my review tomorrow. Sorry for the
delay.
Wolfgang.
^ permalink raw reply
* Sharing VF device among Xen VMs
From: Satish Chowdhury @ 2009-11-15 9:52 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
* Re: [net-next-2.6 PATCH] net: fast consecutive name allocation
From: Eric Dumazet @ 2009-11-15 7:48 UTC (permalink / raw)
To: Denys Fedoryschenko
Cc: Mark Smith, David Miller, bcrl, shemminger, opurdila, netdev
In-Reply-To: <200911150355.15204.denys@visp.net.lb>
Denys Fedoryschenko a écrit :
> On Sunday 15 November 2009 00:36:04 Mark Smith wrote:
>> 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
> I am running up to 3500 on single NAS, but there is only 3 biggest one like
> this, and i am limited only by subscribers on this location (network is
> distributed over the country, and i have around 200 NAS servers running in
> summary). And it is just PC bought from nearest supermarket with cheap PCI
> RTL8169, and similar quality LOM adapter e1000e. Everything running on
> cheapest USB flash from same supermarket.
>
> For my case running Linux NAS on cheap PC's is only choice. It is 3rd world
> country, and many reasons (i can explain each, but it is not technical
> subject) doesn't let me to think, that "professional" equipment is feasible
> for me.
>
> Here people build networks on cheapest unmanageable switches, same
> cost/quality 802.11b/g wireless networks, and only a way to terminate them
> reliably is PPPoE. I know, it is also weak and easy to break, but it is
> single choice i have.
> I know also ISP's in Russia, who have somehow partially "managed" networks,
> but PPPoE letting them to drop running costs.
>
> And interface creation speed is important for me, when electricity goes down
> here, many customers disconnects (up to 500 on single NAS), and then join
> again to NAS. Load average was jumping to sky on such situations, just option
> to not create sysfs entries helped me a lot (was posted recently).
> Electricity outage is usual here, happens 2-3 times daily.
I found in my cases (not pppoe) that load was very high because of udev,
doing crazy loops of :
if (!rtnl_trylock())
return restart_syscall();
About pppoe, we have a 16 slots hash table, protected by a single rwlock.
This wont scale to 50000 sessions, unless we use larger hashtable and
maybe RCU as well.
About the dismantling phase, it is currently a synchronous thing
(as the resquester process has to wait for many rcu grace periods
for each netdevice to dismantle). Thats typically ~20 ms per device !
For 'anonymous' netdevices, we probably could queue them and use a
worker thread to handle this queue using the new batch mode,
added in net-next-2.6.
^ permalink raw reply
* Re: [PATCH] act_mirred: cleanup and optimization
From: jamal @ 2009-11-15 6:13 UTC (permalink / raw)
To: xiaosuo; +Cc: Stephen Hemminger, David S. Miller, netdev
In-Reply-To: <4AFCF06B.1090602@gmail.com>
On Fri, 2009-11-13 at 13:36 +0800, Changli Gao wrote:
> act_mirred: cleanup and optimization.
>
> cleanup and optimization.
> 1. don't let go back using goto.
> 2. move checking if eaction is valid in tcf_mirred_init().
> 3. don't call skb_act_clone() until it is necessary.
> 4. one exit of the critical context.
> 5. allow eaction is TCA_INGRESS_MIRROR & TCA_INGRESS_REDIR.
>
I would break this into the following patches:
patch 1: #1, #3, and #4 (this is what we discussed before)
patch 2: #2 (Ive had this in my todo list forever)
For #5 i think you misunderstood me earlier - TCA_INGRESS_* means
not to do dev xmit (that is the domain of TCA_EGRESS_*) but rather
something along the lines of netif_rx; this needs a lot of
validation - the code has changed quiet a bit since the early days
and as it has turned out noone has exactly been shedding any tears
for that feature. The challenge is in the variety of netdevices which
have different semantics..
Sorry - I am in some hectic travel mode (hence delayed response)
but to answer your earlier question: no you cant redirect to packet
socket today.
cheers,
jamal
^ permalink raw reply
* Re: [NEXT 1/1] Please pull small fix for ieee802.15.4
From: David Miller @ 2009-11-15 4:25 UTC (permalink / raw)
To: dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20091112211715.GA13347-nIupHZaCssqR2kOLt6zJ8ErlnG4Plg33XqFh9Ls21Oc@public.gmane.org>
From: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Fri, 13 Nov 2009 00:17:15 +0300
> git://git.kernel.org/pub/scm/linux/kernel/git/lowpan/lowpan.git for-next
Pulled, thanks.
------------------------------------------------------------------------------
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
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net: fast consecutive name allocation
From: Denys Fedoryschenko @ 2009-11-15 1:55 UTC (permalink / raw)
To: Mark Smith; +Cc: David Miller, bcrl, shemminger, opurdila, eric.dumazet, netdev
In-Reply-To: <20091115090604.331d75c2@opy.nosense.org>
On Sunday 15 November 2009 00:36:04 Mark Smith wrote:
> 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
I am running up to 3500 on single NAS, but there is only 3 biggest one like
this, and i am limited only by subscribers on this location (network is
distributed over the country, and i have around 200 NAS servers running in
summary). And it is just PC bought from nearest supermarket with cheap PCI
RTL8169, and similar quality LOM adapter e1000e. Everything running on
cheapest USB flash from same supermarket.
For my case running Linux NAS on cheap PC's is only choice. It is 3rd world
country, and many reasons (i can explain each, but it is not technical
subject) doesn't let me to think, that "professional" equipment is feasible
for me.
Here people build networks on cheapest unmanageable switches, same
cost/quality 802.11b/g wireless networks, and only a way to terminate them
reliably is PPPoE. I know, it is also weak and easy to break, but it is
single choice i have.
I know also ISP's in Russia, who have somehow partially "managed" networks,
but PPPoE letting them to drop running costs.
And interface creation speed is important for me, when electricity goes down
here, many customers disconnects (up to 500 on single NAS), and then join
again to NAS. Load average was jumping to sky on such situations, just option
to not create sysfs entries helped me a lot (was posted recently).
Electricity outage is usual here, happens 2-3 times daily.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net: fast consecutive name allocation
From: Mark Smith @ 2009-11-15 1:49 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, bcrl, opurdila, eric.dumazet, netdev
In-Reply-To: <20091114172224.5ca4c94e@s6510>
On Sat, 14 Nov 2009 17:22:24 -0800
Stephen Hemminger <shemminger@vyatta.com> wrote:
> 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.
I don't really think that is the case. The authors of the PPPoE
spec were all from "Internet" companies, including UUNET, the first
Internet company, and the largest at the time, so I'm sure they all knew
about Internet scaling.
Here's what they had to say in the RFC2516 intro:
" Modern access technologies are faced with several conflicting goals.
It is desirable to connect multiple hosts at a remote site through
the same customer premise access device. It is also a goal to
provide access control and billing functionality in a manner similar
to dial-up services using PPP. In many access technologies, the most
cost effective method to attach multiple hosts to the customer
premise access device, is via Ethernet. In addition, it is desirable
to keep the cost of this device as low as possible while requiring
little or no configuration."
^ permalink raw reply
* 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
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