* 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-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: 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: [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: [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: [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
* 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: [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
* 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
* [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
* 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
* 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
* 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
* [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: [RFC] vlan: GRO rx statistics
From: Eric Dumazet @ 2009-11-15 19:35 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:
>> Still the race while updating dev->stats.tx_{bytes|packets} should be addressed eventually...
>
> Well making it per-napi_struct should do the trick.
For normal devices, probably (but many of them use hardware counters anyway)
but not vlan :)
vlan_hwaccel_do_receive() has no napi context.
^ permalink raw reply
* Pull request: bluetooth-2.6 2009-11-16
From: Marcel Holtmann @ 2009-11-16 0:48 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
Hi Dave,
here are three additional patches that should go into 2.6.32 before its
final release.
The first one fixes a regression with Secure Simple Pairing support. I
had that patch for a while, but it took some time to verify that it
doesn't break the Bluetooth qualification. The Bluetooth 2.1 GAP testing
is a major pain and always surprises you.
The second and third patches are fixing two regression from the L2CAP
ERTM support. When ERTM is not supported or not configured we have to
use Basic Mode and really stick to it. Other Bluetooth stacks are not
capable of handling unknown options properly.
Regards
Marcel
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6.git master
This will update the following files:
net/bluetooth/hci_conn.c | 1 +
net/bluetooth/l2cap.c | 13 +++++++++----
2 files changed, 10 insertions(+), 4 deletions(-)
through these ChangeSets:
Andrei Emeltchenko (1):
Bluetooth: Set general bonding security for ACL by default
Gustavo F. Padovan (2):
Bluetooth: Select Basic Mode as default for SOCK_SEQPACKET
Bluetooth: Fix regression with L2CAP configuration in Basic Mode
^ permalink raw reply
* [PATCH 1/3] Bluetooth: Set general bonding security for ACL by default
From: Marcel Holtmann @ 2009-11-16 0:48 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <cover.1258331614.git.marcel@holtmann.org>
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
This patch fixes double pairing issues with Secure Simple
Paring support. It was observed that when pairing with SSP
enabled, that the confirmation will be asked twice.
http://www.spinics.net/lists/linux-bluetooth/msg02473.html
This also causes bug when initiating SSP connection from
Windows Vista.
The reason is because bluetoothd does not store link keys
since HCIGETAUTHINFO returns 0. Setting default to general
bonding fixes these issues.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/hci_conn.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index a975098..b7c4224 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -211,6 +211,7 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst)
conn->type = type;
conn->mode = HCI_CM_ACTIVE;
conn->state = BT_OPEN;
+ conn->auth_type = HCI_AT_GENERAL_BONDING;
conn->power_save = 1;
conn->disc_timeout = HCI_DISCONN_TIMEOUT;
--
1.6.2.5
^ permalink raw reply related
* [PATCH 2/3] Bluetooth: Select Basic Mode as default for SOCK_SEQPACKET
From: Marcel Holtmann @ 2009-11-16 0:48 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <cover.1258331614.git.marcel@holtmann.org>
From: Gustavo F. Padovan <gustavo@las.ic.unicamp.br>
The default mode for SOCK_SEQPACKET is Basic Mode. So when no
mode has been specified, Basic Mode shall be used.
This is important for current application to keep working as
expected and not cause a regression.
Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/l2cap.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 77e9fb1..076caa1 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -2205,7 +2205,7 @@ static int l2cap_build_conf_req(struct sock *sk, void *data)
{
struct l2cap_pinfo *pi = l2cap_pi(sk);
struct l2cap_conf_req *req = data;
- struct l2cap_conf_rfc rfc = { .mode = L2CAP_MODE_ERTM };
+ struct l2cap_conf_rfc rfc = { .mode = L2CAP_MODE_BASIC };
void *ptr = req->data;
BT_DBG("sk %p", sk);
--
1.6.2.5
^ permalink raw reply related
* [PATCH 3/3] Bluetooth: Fix regression with L2CAP configuration in Basic Mode
From: Marcel Holtmann @ 2009-11-16 0:48 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <cover.1258331614.git.marcel@holtmann.org>
From: Gustavo F. Padovan <gustavo@las.ic.unicamp.br>
Basic Mode is the default mode of operation of a L2CAP entity. In
this case the RFC (Retransmission and Flow Control) configuration
option should not be used at all.
Normally remote L2CAP implementation should just ignore this option,
but it can cause various side effects with other Bluetooth stacks
that are not capable of handling unknown options.
Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/l2cap.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 076caa1..947f8bb 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -2394,6 +2394,10 @@ done:
rfc.monitor_timeout = L2CAP_DEFAULT_MONITOR_TO;
pi->conf_state |= L2CAP_CONF_MODE_DONE;
+
+ l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC,
+ sizeof(rfc), (unsigned long) &rfc);
+
break;
case L2CAP_MODE_STREAMING:
@@ -2401,6 +2405,10 @@ done:
pi->max_pdu_size = rfc.max_pdu_size;
pi->conf_state |= L2CAP_CONF_MODE_DONE;
+
+ l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC,
+ sizeof(rfc), (unsigned long) &rfc);
+
break;
default:
@@ -2410,9 +2418,6 @@ done:
rfc.mode = pi->mode;
}
- l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC,
- sizeof(rfc), (unsigned long) &rfc);
-
if (result == L2CAP_CONF_SUCCESS)
pi->conf_state |= L2CAP_CONF_OUTPUT_DONE;
}
--
1.6.2.5
^ permalink raw reply related
* Re: Problem with VLANs and via-velocity driver
From: Kevin Shanahan @ 2009-11-16 0:57 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev
In-Reply-To: <4AFCFF67.3060802@trash.net>
On Fri, Nov 13, 2009 at 07:40:39AM +0100, Patrick McHardy wrote:
> Kevin Shanahan wrote:
> > Hi,
> >
> > I've had some problems with getting a fairly simple (I thought) VLAN
> > configuration working with the on board Via NICs on my Via M700
> > board. Looks like as soon as a tagged VLAN interface is added, the
> > underlying "raw" (untagged) interface stops responding.
> >
> > ...
> >
> > A bit of searching found a few references to similar problems going
> > back a few years (2005, 2007). Sounded like there were some driver
> > issues, but it wasn't clear from the messages I found whether they
> > were believed to be fixed or not. I tried the same test using a
> > differnt NIC with the tg3 driver and there were no problems, so it
> > looks to me like it's still a via-velocity issue. Unfortunately I
> > don't have room to add NICs to this machine and need to use the on
> > board Via hardware.
>
> There's some special-casing for VID 0 in velocity_init_cam_filter().
> Does "ip link add link eth0 type vlan id 0" make any difference?
Thanks Patrick, this command got the untagged interface working again
(eth1 in my case). I can use this as a work around.
I didn't really understand if there was a good reason for the
special-casing in this driver, but from at least from my user
perspective I think it would be better if the drivers were consistent
in how they handle this.
Regards,
Kevin Shanahan.
^ permalink raw reply
* [PATCH v1 resent] net: TCP_MSS_DEFAULT, TCP_MSS_DESIRED
From: William Allen Simpson @ 2009-11-16 1:18 UTC (permalink / raw)
To: Linux Kernel Network Developers; +Cc: Linux Kernel Developers, David Miller
[-- Attachment #1: Type: text/plain, Size: 694 bytes --]
Define two symbols needed in both kernel and user space.
Remove old (somewhat incorrect) kernel variant that wasn't used in
most cases. Default should apply to both RMSS and SMSS (RFC2581).
Replace numeric constants with defined symbols.
Stand-alone patch, originally developed for TCPCT.
Signed-off-by: William.Allen.Simpson@gmail.com
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/linux/tcp.h | 6 ++++++
include/net/tcp.h | 3 ---
net/ipv4/tcp_input.c | 4 ++--
net/ipv4/tcp_ipv4.c | 6 +++---
net/ipv4/tcp_minisocks.c | 2 +-
net/ipv6/tcp_ipv6.c | 2 +-
6 files changed, 13 insertions(+), 10 deletions(-)
[-- Attachment #2: TCP_MSSv1.patch --]
[-- Type: text/plain, Size: 4018 bytes --]
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index eeecb85..32d7d77 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -81,6 +81,12 @@ enum {
TCP_DATA_OFFSET = __cpu_to_be32(0xF0000000)
};
+/*
+ * TCP general constants
+ */
+#define TCP_MSS_DEFAULT 536U /* IPv4 (RFC1122, RFC2581) */
+#define TCP_MSS_DESIRED 1220U /* IPv6 (tunneled), EDNS0 (RFC3226) */
+
/* TCP socket options */
#define TCP_NODELAY 1 /* Turn off Nagle's algorithm. */
#define TCP_MAXSEG 2 /* Limit MSS */
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 25bf3ba..a413e9f 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -62,9 +62,6 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
/* Minimal accepted MSS. It is (60+60+8) - (20+20). */
#define TCP_MIN_MSS 88U
-/* Minimal RCV_MSS. */
-#define TCP_MIN_RCVMSS 536U
-
/* The least MTU to use for probing */
#define TCP_BASE_MSS 512
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index be0c5bf..cc306ac 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -140,7 +140,7 @@ static void tcp_measure_rcv_mss(struct sock *sk, const struct sk_buff *skb)
* "len" is invariant segment length, including TCP header.
*/
len += skb->data - skb_transport_header(skb);
- if (len >= TCP_MIN_RCVMSS + sizeof(struct tcphdr) ||
+ if (len >= TCP_MSS_DEFAULT + sizeof(struct tcphdr) ||
/* If PSH is not set, packet should be
* full sized, provided peer TCP is not badly broken.
* This observation (if it is correct 8)) allows
@@ -411,7 +411,7 @@ void tcp_initialize_rcv_mss(struct sock *sk)
unsigned int hint = min_t(unsigned int, tp->advmss, tp->mss_cache);
hint = min(hint, tp->rcv_wnd / 2);
- hint = min(hint, TCP_MIN_RCVMSS);
+ hint = min(hint, TCP_MSS_DEFAULT);
hint = max(hint, TCP_MIN_MSS);
inet_csk(sk)->icsk_ack.rcv_mss = hint;
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index f83ac91..0718fde 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -217,7 +217,7 @@ int tcp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
if (inet->opt)
inet_csk(sk)->icsk_ext_hdr_len = inet->opt->optlen;
- tp->rx_opt.mss_clamp = 536;
+ tp->rx_opt.mss_clamp = TCP_MSS_DEFAULT;
/* Socket identity is still unknown (sport may be zero).
* However we set state to SYN-SENT and not releasing socket
@@ -1270,7 +1270,7 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
goto drop_and_free;
tcp_clear_options(&tmp_opt);
- tmp_opt.mss_clamp = 536;
+ tmp_opt.mss_clamp = TCP_MSS_DEFAULT;
tmp_opt.user_mss = tcp_sk(sk)->rx_opt.user_mss;
tcp_parse_options(skb, &tmp_opt, 0, dst);
@@ -1818,7 +1818,7 @@ static int tcp_v4_init_sock(struct sock *sk)
*/
tp->snd_ssthresh = TCP_INFINITE_SSTHRESH;
tp->snd_cwnd_clamp = ~0;
- tp->mss_cache = 536;
+ tp->mss_cache = TCP_MSS_DEFAULT;
tp->reordering = sysctl_tcp_reordering;
icsk->icsk_ca_ops = &tcp_init_congestion_ops;
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index fb68bab..7a42990 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -476,7 +476,7 @@ struct sock *tcp_create_openreq_child(struct sock *sk, struct request_sock *req,
if (newtp->af_specific->md5_lookup(sk, newsk))
newtp->tcp_header_len += TCPOLEN_MD5SIG_ALIGNED;
#endif
- if (skb->len >= TCP_MIN_RCVMSS+newtp->tcp_header_len)
+ if (skb->len >= TCP_MSS_DEFAULT + newtp->tcp_header_len)
newicsk->icsk_ack.last_seg_size = skb->len - newtp->tcp_header_len;
newtp->rx_opt.mss_clamp = req->mss;
TCP_ECN_openreq_child(newtp, req);
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 6951827..b528f75 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1849,7 +1849,7 @@ static int tcp_v6_init_sock(struct sock *sk)
*/
tp->snd_ssthresh = TCP_INFINITE_SSTHRESH;
tp->snd_cwnd_clamp = ~0;
- tp->mss_cache = 536;
+ tp->mss_cache = TCP_MSS_DEFAULT;
tp->reordering = sysctl_tcp_reordering;
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH v1 resent] net: TCP_MSS_DEFAULT, TCP_MSS_DESIRED
From: David Miller @ 2009-11-16 4:54 UTC (permalink / raw)
To: william.allen.simpson; +Cc: netdev, linux-kernel
In-Reply-To: <4B00A858.8000705@gmail.com>
I already applied this patch to net-next-2.6, there is no need
to resend it.
^ permalink raw reply
* Re: Pull request: bluetooth-2.6 2009-11-16
From: David Miller @ 2009-11-16 5:01 UTC (permalink / raw)
To: marcel; +Cc: netdev
In-Reply-To: <cover.1258331614.git.marcel@holtmann.org>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Mon, 16 Nov 2009 01:48:20 +0100
> Please pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6.git master
Pulled, thanks a lot.
^ permalink raw reply
* Re: [PATCH net-next-2.6] r6040: fix version printing
From: David Miller @ 2009-11-16 5:15 UTC (permalink / raw)
To: florian; +Cc: netdev
In-Reply-To: <200911151449.43750.florian@openwrt.org>
From: Florian Fainelli <florian@openwrt.org>
Date: Sun, 15 Nov 2009 14:49:43 +0100
> 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>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] can: add the missing netlink get_xstats_size callback
From: David Miller @ 2009-11-16 5:16 UTC (permalink / raw)
To: wg; +Cc: netdev, socketcan-core
In-Reply-To: <4AFFECCC.8000204@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
Date: Sun, 15 Nov 2009 12:58:04 +0100
> David Miller wrote:
>> From: Wolfgang Grandegger <wg@grandegger.com>
>> 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@grandegger.com>
>>
>> Applied.
>
> It would make sense to apply this patch to net-2.6 as well.
I only applied it to net-2.6
^ 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