* Re: [Announce] LARTC wiki available
From: Andy Furniss @ 2012-06-02 14:43 UTC (permalink / raw)
To: Julien Vehent
Cc: Niccolò Belli, lartc, netfilter,
Linux Networking Developer Mailing List
In-Reply-To: <4FCA2545.60702@ukfsn.org>
Andy Furniss wrote:
> I tested (maybe not hard enough) quantum < mtu and never managed to
> prevent dequeues - I know it's not efficient and "forbiden" but back
> then at least it didn't break.
Forgot to say -
also remember mtu as seen by tc on eth has 14 added - default quantum on
sfq, htb etc are 1514 as you can see with tc -s -d qdisc ls etc.
^ permalink raw reply
* Re: Network hangs on current git kernel
From: Eric Dumazet @ 2012-06-02 15:48 UTC (permalink / raw)
To: Markus Trippelsdorf; +Cc: Francois Romieu, netdev
In-Reply-To: <20120602112334.GA10145@x4>
On Sat, 2012-06-02 at 13:23 +0200, Markus Trippelsdorf wrote:
> On 2012.06.02 at 13:15 +0200, Eric Dumazet wrote:
> > On Sat, 2012-06-02 at 12:57 +0200, Francois Romieu wrote:
> > > Eric Dumazet <eric.dumazet@gmail.com> :
> > > > On Sat, 2012-06-02 at 10:25 +0200, Markus Trippelsdorf wrote:
> > > [hang]
> > > > Maybe tell us what NIC it is, that sort of things...
> > >
> > > As well as 'ip -s link' and complete dmesg from boot.
> > > Kernel .config may be.
> >
> > yes, and "netstat -s" is always useful
>
> It's an ATL1E NIC. The kernel config is attached.
Driver tx completion is buggy, but it should hang forever...
If you ping your local gateway, you also have 'hangs' ?
^ permalink raw reply
* Re: [Announce] LARTC wiki available
From: Eric Dumazet @ 2012-06-02 15:50 UTC (permalink / raw)
To: Andy Furniss
Cc: Julien Vehent, Niccolò Belli, lartc, netfilter,
Linux Networking Developer Mailing List
In-Reply-To: <4FCA2545.60702@ukfsn.org>
On Sat, 2012-06-02 at 15:37 +0100, Andy Furniss wrote:
>
> Anyway it seems that early this year SFQ got some love and now has
> several more options (red, headdrop, limit >127, depth as param) - so as
> long as your iproute/kernel is current have a look at man tc-sfq for
> details.
Yes, but fq_codel is really better than SFQ.
^ permalink raw reply
* Re: Network hangs on current git kernel
From: Markus Trippelsdorf @ 2012-06-02 16:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Francois Romieu, netdev
In-Reply-To: <1338652120.2760.1705.camel@edumazet-glaptop>
On 2012.06.02 at 17:48 +0200, Eric Dumazet wrote:
> On Sat, 2012-06-02 at 13:23 +0200, Markus Trippelsdorf wrote:
> > On 2012.06.02 at 13:15 +0200, Eric Dumazet wrote:
> > > On Sat, 2012-06-02 at 12:57 +0200, Francois Romieu wrote:
> > > > Eric Dumazet <eric.dumazet@gmail.com> :
> > > > > On Sat, 2012-06-02 at 10:25 +0200, Markus Trippelsdorf wrote:
> > > > [hang]
> > > > > Maybe tell us what NIC it is, that sort of things...
> > > >
> > > > As well as 'ip -s link' and complete dmesg from boot.
> > > > Kernel .config may be.
> > >
> > > yes, and "netstat -s" is always useful
> >
> > It's an ATL1E NIC. The kernel config is attached.
>
> Driver tx completion is buggy, but it should hang forever...
>
> If you ping your local gateway, you also have 'hangs' ?
Will keep an eye on that.
After all this could well be just a buggy router, that broke in the last
few days by coincidence...
--
Markus
^ permalink raw reply
* Re: [Announce] LARTC wiki available
From: Andy Furniss @ 2012-06-02 16:58 UTC (permalink / raw)
To: Eric Dumazet
Cc: Julien Vehent, Niccolò Belli, lartc, netfilter,
Linux Networking Developer Mailing List
In-Reply-To: <1338652231.2760.1706.camel@edumazet-glaptop>
Eric Dumazet wrote:
> On Sat, 2012-06-02 at 15:37 +0100, Andy Furniss wrote:
>
>>
>> Anyway it seems that early this year SFQ got some love and now has
>> several more options (red, headdrop, limit>127, depth as param) - so as
>> long as your iproute/kernel is current have a look at man tc-sfq for
>> details.
>
> Yes, but fq_codel is really better than SFQ.
Ooh, that does look interesting. I hadn't seen that, thanks.
I should really start checking netdev again.
Just pulled iproute git, and see there is a man for codel, but not
fq_codel (yet?).
It would be handy if it/them were added to man tc's "SEE ALSO" section.
^ permalink raw reply
* Re: Network hangs on current git kernel
From: Markus Trippelsdorf @ 2012-06-02 17:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Francois Romieu, netdev
In-Reply-To: <20120602163437.GA16598@x4>
On 2012.06.02 at 18:34 +0200, Markus Trippelsdorf wrote:
> On 2012.06.02 at 17:48 +0200, Eric Dumazet wrote:
> > On Sat, 2012-06-02 at 13:23 +0200, Markus Trippelsdorf wrote:
> > > On 2012.06.02 at 13:15 +0200, Eric Dumazet wrote:
> > > > On Sat, 2012-06-02 at 12:57 +0200, Francois Romieu wrote:
> > > > > Eric Dumazet <eric.dumazet@gmail.com> :
> > > > > > On Sat, 2012-06-02 at 10:25 +0200, Markus Trippelsdorf wrote:
> > > > > [hang]
> > > > > > Maybe tell us what NIC it is, that sort of things...
> > > > >
> > > > > As well as 'ip -s link' and complete dmesg from boot.
> > > > > Kernel .config may be.
> > > >
> > > > yes, and "netstat -s" is always useful
> > >
> > > It's an ATL1E NIC. The kernel config is attached.
> >
> > Driver tx completion is buggy, but it should hang forever...
> >
> > If you ping your local gateway, you also have 'hangs' ?
>
> Will keep an eye on that.
> After all this could well be just a buggy router, that broke in the last
> few days by coincidence...
And indeed it must be a buggy router:
(all pings were collected in parallel)
--- heise.de ping statistics ---
128 packets transmitted, 110 received, 14% packet loss, time 127232ms
rtt min/avg/max/mdev = 21.684/23.611/49.691/3.211 ms
--- 192.168.1.1 (local router) ping statistics ---
126 packets transmitted, 126 received, 0% packet loss, time 125004ms
rtt min/avg/max/mdev = 0.095/0.222/0.336/0.060 ms
--- localhost ping statistics ---
127 packets transmitted, 127 received, 0% packet loss, time 126001ms
rtt min/avg/max/mdev = 0.009/0.029/0.065/0.011 ms
Sorry for the noise!
--
Markus
^ permalink raw reply
* Re: [PATCH 1/1] fec_mpc52xx: fix timestamp filtering
From: Richard Cochran @ 2012-06-02 19:06 UTC (permalink / raw)
To: Stephan Gatzka; +Cc: netdev, davem, stable
In-Reply-To: <1338642246-10911-1-git-send-email-stephan@gatzka.org>
On Sat, Jun 02, 2012 at 03:04:06PM +0200, Stephan Gatzka wrote:
> skb_defer_rx_timestamp was called with a freshly allocated skb but must
> be called with rskb instead.
Thanks for checking this, and sorry for the trouble it caused you.
Acked-by: Richard Cochran <richardcochran@gmail.com>
>
> Signed-off-by: Stephan Gatzka <stephan@gatzka.org>
> Cc: stable <stable@vger.kernel.org>
> ---
> drivers/net/ethernet/freescale/fec_mpc52xx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec_mpc52xx.c b/drivers/net/ethernet/freescale/fec_mpc52xx.c
> index 97f947b..2933d08 100644
> --- a/drivers/net/ethernet/freescale/fec_mpc52xx.c
> +++ b/drivers/net/ethernet/freescale/fec_mpc52xx.c
> @@ -437,7 +437,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
> length = status & BCOM_FEC_RX_BD_LEN_MASK;
> skb_put(rskb, length - 4); /* length without CRC32 */
> rskb->protocol = eth_type_trans(rskb, dev);
> - if (!skb_defer_rx_timestamp(skb))
> + if (!skb_defer_rx_timestamp(rskb))
> netif_rx(rskb);
>
> spin_lock(&priv->lock);
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH iproute2] Add reference to tc-codel(8) to the SEE ALSO section
From: Jan Ceuleers @ 2012-06-02 19:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: andyqos, netdev
Reported-by: Andy Furniss <andyqos@ukfsn.org>
Signed-off-by: Jan Ceuleers <jan.ceuleers@computer.org>
---
man/man8/tc.8 | 1 +
1 file changed, 1 insertion(+)
diff --git a/man/man8/tc.8 b/man/man8/tc.8
index 6576377..14a1cd8 100644
--- a/man/man8/tc.8
+++ b/man/man8/tc.8
@@ -368,6 +368,7 @@ was written by Alexey N. Kuznetsov and added in Linux 2.2.
.SH SEE ALSO
.BR tc-cbq (8),
.BR tc-choke (8),
+.BR tc-codel (8),
.BR tc-drr (8),
.BR tc-htb (8),
.BR tc-hfsc (8),
--
1.7.9.5
^ permalink raw reply related
* Re: [net 0/2][pull request] Intel Wired LAN Driver Update
From: David Miller @ 2012-06-02 21:08 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1338621416-22425-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sat, 2 Jun 2012 00:16:54 -0700
> This series contains fixes for e1000 and e1000e.
>
> The following are changes since commit ad1be8d345416a794dea39761a374032aa471a76:
> r8169: call netif_napi_del at errpaths and at driver unload
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net master
>
> Bruce Allan (1):
> e1000e: fix Rapid Start Technology support for i217
>
> Sebastian Andrzej Siewior (1):
> e1000: look into the page instead of skb->data for
> e1000_tbi_adjust_stats()
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH] mcs7830: Implement link state detection
From: David Miller @ 2012-06-02 21:09 UTC (permalink / raw)
To: linux; +Cc: andi, netdev, linux-kernel
In-Reply-To: <201206012229.11530.linux@rainbow-software.org>
From: Ondrej Zary <linux@rainbow-software.org>
Date: Fri, 1 Jun 2012 22:29:08 +0200
> Add .status callback that detects link state changes.
> Tested with MCS7832CV-AA chip (9710:7830, identified as rev.C by the driver).
> Fixes https://bugzilla.kernel.org/show_bug.cgi?id=28532
>
> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] fec_mpc52xx: fix timestamp filtering
From: David Miller @ 2012-06-02 21:09 UTC (permalink / raw)
To: richardcochran; +Cc: stephan, netdev, stable
In-Reply-To: <20120602190605.GA2202@netboy.at.omicron.at>
From: Richard Cochran <richardcochran@gmail.com>
Date: Sat, 2 Jun 2012 21:06:05 +0200
> On Sat, Jun 02, 2012 at 03:04:06PM +0200, Stephan Gatzka wrote:
>> skb_defer_rx_timestamp was called with a freshly allocated skb but must
>> be called with rskb instead.
>
> Thanks for checking this, and sorry for the trouble it caused you.
>
> Acked-by: Richard Cochran <richardcochran@gmail.com>
Applied.
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2012-06-02 21:31 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Make syn floods consume significantly less resources by
a) Not pre-COW'ing routing metrics for SYN/ACKs
b) Mirroring the device queue mapping of the SYN for the SYN/ACK
reply.
Both from Eric Dumazet.
2) Fix calculation errors in Byte Queue Limiting, from Hiroaki SHIMODA.
3) Validate the length requested when building a paged SKB for a
socket, so we don't overrun the page vector accidently. From Jason
Wang.
4) When netlabel is disabled, we abort all IP option processing when
we see a CIPSO option. This isn't the right thing to do, we should
simply skip over it and continue processing the remaining options
(if any). Fix from Paul Moore.
5) SRIOV fixes for the mellanox driver from Jack orgenstein and Marcel
Apfelbaum.
6) 8139cp enables the receiver before the ring address is properly
programmed, which potentially lets the device crap over random
memory. Fix from Jason Wang.
7) e1000/e1000e fixes for i217 RST handling, and an improper buffer
address reference in jumbo RX frame processing from Bruce Allan
and Sebastian Andrzej Siewior, respectively.
Please pull, thanks a lot!
The following changes since commit 76f901eb4659779ecacd0e4eba49f55442daef53:
Merge tag 'for-v3.5' of git://git.infradead.org/battery-2.6 (2012-05-31 12:10:15 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
for you to fetch changes up to 9ca3cc6f3026946ba655e863ca2096339e667639:
fec_mpc52xx: fix timestamp filtering (2012-06-02 17:09:08 -0400)
----------------------------------------------------------------
Bruce Allan (1):
e1000e: fix Rapid Start Technology support for i217
Devendra Naga (1):
r8169: call netif_napi_del at errpaths and at driver unload
Eric Dumazet (2):
tcp: do not create inetpeer on SYNACK message
tcp: reflect SYN queue_mapping into SYNACK packets
Hiroaki SHIMODA (3):
bql: Fix POSDIFF() to integer overflow aware.
bql: Avoid unneeded limit decrement.
bql: Avoid possible inconsistent calculation.
Jack Morgenstein (5):
net/mlx4_core: Fix the slave_id out-of-range test in mlx4_eq_int
net/mlx4_en: Fix improper use of "port" parameter in mlx4_en_event
net/mlx4_core: Fixes for VF / Guest startup flow
net/mlx4_core: Check port out-of-range before using in mlx4_slave_cap
net/mlx4_core: Fix obscure mlx4_cmd_box parameter in QUERY_DEV_CAP
Jason Wang (3):
net: sock: validate data_len before allocating skb in sock_alloc_send_pskb()
8139cp: set ring address before enabling receiver
8139cp/8139too: terminate the eeprom access with the right opmode
Marcel Apfelbaum (1):
net/mlx4_core: Fix number of EQs used in ICM initialisation
Ondrej Zary (1):
mcs7830: Implement link state detection
Paul Moore (1):
cipso: handle CIPSO options correctly when NetLabel is disabled
Sebastian Andrzej Siewior (1):
e1000: look into the page instead of skb->data for e1000_tbi_adjust_stats()
Stephan Gatzka (1):
fec_mpc52xx: fix timestamp filtering
drivers/net/ethernet/freescale/fec_mpc52xx.c | 2 +-
drivers/net/ethernet/intel/e1000/e1000_main.c | 2 +-
drivers/net/ethernet/intel/e1000e/ich8lan.c | 18 +++++++++---------
drivers/net/ethernet/mellanox/mlx4/cmd.c | 4 ++--
drivers/net/ethernet/mellanox/mlx4/en_main.c | 12 +++++++-----
drivers/net/ethernet/mellanox/mlx4/eq.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/fw.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++---
drivers/net/ethernet/mellanox/mlx4/main.c | 40 +++++++++++++--------------------------
drivers/net/ethernet/mellanox/mlx4/mlx4.h | 10 ++++++++++
drivers/net/ethernet/mellanox/mlx4/profile.c | 9 ++++++---
drivers/net/ethernet/realtek/8139cp.c | 24 ++++++++++++------------
drivers/net/ethernet/realtek/8139too.c | 2 +-
drivers/net/ethernet/realtek/r8169.c | 3 +++
drivers/net/usb/mcs7830.c | 25 +++++++++++++++++++++++--
include/linux/mlx4/device.h | 6 ++++++
include/net/cipso_ipv4.h | 29 +++++++++++++++++++++++++++-
lib/dynamic_queue_limits.c | 18 +++++++++++-------
net/core/sock.c | 7 +++++--
net/ipv4/inet_connection_sock.c | 3 ++-
net/ipv4/tcp_ipv4.c | 9 ++++++---
net/ipv6/tcp_ipv6.c | 9 ++++++---
21 files changed, 201 insertions(+), 84 deletions(-)
^ permalink raw reply
* Bug report: RT2800USB driver. txpower stuck at 0
From: Vilius Palme @ 2012-06-02 21:59 UTC (permalink / raw)
To: netdev
Hello.
Is this the place to report net driver bugs?
Just tried to make a switch from 3.3.5 to 3.4.0 kernel and it seems
that something is wrong with RT2800USB driver. iwlwifi driver seems to
work pretty fine, so I assume that this is RT driver problem.
Here's some info:
[root@R1 iw]# uname -a
Linux R1 3.4.0 #4 SMP PREEMPT Sat Jun 2 21:22:40 CEST 2012 x86_64 GNU/Linux
[root@R1 iw]# ifconfig wlan0 up
[root@R1 iw]# iwconfig wlan0
wlan0 IEEE 802.11bgn ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=0 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
[root@R1 iw]# iwconfig wlan0 txpower 20
Error for wireless request "Set Tx Power" (8B26) :
SET failed on device wlan0 ; Invalid argument.
[root@R1 iw]# iwconfig wlan0 txpower 1
Error for wireless request "Set Tx Power" (8B26) :
SET failed on device wlan0 ; Invalid argument.
[root@R1 iw]# iwconfig wlan0 txpower 0
[root@R1 iw]#
[root@R1 iw]# rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
Soft blocked: no
Hard blocked: no
27: phy26: Wireless LAN
Soft blocked: no
Hard blocked: no
[root@R1 iw]#
lsusb -vv output:
Bus 002 Device 020: ID 1737:0078 Linksys WUSB100 v2 RangePlus Wireless
Network Adapter [Ralink RT3070]
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1737 Linksys
idProduct 0x0078 WUSB100 v2 RangePlus Wireless Network
Adapter [Ralink RT3070]
bcdDevice 1.01
iManufacturer 1 Cisco-Linksys LLC
iProduct 2 Linksys RangePlus Wireless Network USB Adapter
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 67
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 450mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 7
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
Lemme know if I should add some /dev/random or anything else.
Vilius
^ permalink raw reply
* Re: [Announce] LARTC wiki available
From: Jesper Dangaard Brouer @ 2012-06-03 2:36 UTC (permalink / raw)
To: Andy Furniss
Cc: Julien Vehent, Niccolò Belli, lartc, netfilter,
Linux Networking Developer Mailing List, brouer
In-Reply-To: <4FCA2545.60702@ukfsn.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1715 bytes --]
On Sat, 2 Jun 2012, Andy Furniss wrote:
> Julien Vehent wrote:
>> On 2012-06-01 12:42, Niccolò Belli wrote:
>> > http://lartc.org is alive and kicking and there is no need for
>> > another
>> > wiki anymore. I'd like to thank both Bert and Carl-Daniel.
>> >
>> > Niccolò
>> >
>>
>> Very cool !
>> I'll try to find some time and move over some of the content I have
>> here:
>> http://wiki.linuxwall.info/doku.php/en:ressources:dossiers:networking:traffic_control
>
> A couple of things that stand out after skimming through.
>
> DSL - Jeesper's overhead as noted in the comments is not 5 and anyway I think
> his good work has now been superseded by stab as it allows for negative
> overheads, which his did not.
Thanks for the credits :-)
Its been a while since I looked at that code. I think, the 5 bytes might
ref to the ATM header 5 + 48 = 53 bytes the ATM cell size. But 5 is not
used as overhead.
The linklayer ATM hack is to adjust the rtable array, that the kernel uses
for lookups. The problem is that the rtable array only have an 8 bytes
"resolution" (well depend on cell_log), thus to get this aligned, I use
the ATM payload size of 48, when populating the rtable array. Then
when storing the "data" I the rtable array I use *53 byte ATM cell size.
> man tc-stab has clear and good explanations and examples.
Good to see some documentation on stab, I always found it difficult to
use.
Cheers,
Jesper Brouer
--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------
^ permalink raw reply
* Re: Bug report: RT2800USB driver. txpower stuck at 0
From: Jan Ceuleers @ 2012-06-03 7:09 UTC (permalink / raw)
To: Vilius Palme; +Cc: netdev
In-Reply-To: <CAOUAToY-uDxGLk475RvMY2uu9GwQ4dnPfFx0aCz4eO25L=6nDA@mail.gmail.com>
On 06/02/2012 11:59 PM, Vilius Palme wrote:
> Hello.
>
> Is this the place to report net driver bugs?
>
> Just tried to make a switch from 3.3.5 to 3.4.0 kernel and it seems
> that something is wrong with RT2800USB driver. iwlwifi driver seems to
> work pretty fine, so I assume that this is RT driver problem.
janc@mordor:~/git/net-next$ ./scripts/get_maintainer.pl -f
drivers/net/wireless/rt2x00/rt2800usb.c
Ivo van Doorn <IvDoorn@gmail.com> (maintainer:RALINK RT2X00 WIR...)
Gertjan van Wingerde <gwingerde@gmail.com> (maintainer:RALINK RT2X00 WIR...)
Helmut Schaa <helmut.schaa@googlemail.com> (maintainer:RALINK RT2X00 WIR...)
"John W. Linville" <linville@tuxdriver.com> (maintainer:NETWORKING
[WIREL...)
linux-wireless@vger.kernel.org (open list:RALINK RT2X00 WIR...)
users@rt2x00.serialmonkey.com (moderated list:RALINK RT2X00 WIR...)
netdev@vger.kernel.org (open list:NETWORKING DRIVERS)
linux-kernel@vger.kernel.org (open list)
So you've not come to the wrong place exactly, but the linux-wireless
mailing list (being more specialised than netdev) is a forum in which
you are more likely to get someone to look at your issue.
HTH, Jan
^ permalink raw reply
* Re: [PATCH 01/21] datapath: tunnelling: Replace tun_id with tun_key
From: Jesse Gross @ 2012-06-03 9:01 UTC (permalink / raw)
To: Simon Horman; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1337850554-10339-2-git-send-email-horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 9431 bytes --]
On May 24, 2012, at 2:08 AM, Simon Horman wrote:
> this is a first pass at providing a tun_key which can be used
> as the basis for flow-based tunnelling. The tun_key includes and
> replaces the tun_id in both struct ovs_skb_cb and struct sw_tun_key.
>
> In ovs_skb_cb tun_key is a pointer as it is envisaged that it will grow
> when support for IPv6 to an extent that inlining the structure will result
> in ovs_skb_cb being larger than the 48 bytes available in skb->cb.
>
> As OVS does not support IPv6 as the outer transport protocol for tunnels
> the IPv6 portions of this change, which appeared in the previous revision,
> have been dropped in order to limit the scope and size of this patch.
>
> This patch does not make any effort to retain the existing tun_id behaviour
> nor does it fully implement flow-based tunnels. As such it it is incomplete
> and can't be used in its current form (other than to break OVS tunnelling).
>
> ** Please do not apply **
>
> Cc: Kyle Mestery <kmestery-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
Thanks and sorry again about being so slow to look at this.
Overall, this looks pretty good to me. The main difficulty that I had was in figuring out what should go with the old behavior and what should go with the new since it's at an intermediate point between the two but I understand that it's difficult to break it up in a way that both encapsulates a particular set of functionality and isn't too large. Otherwise, I noticed a few specific things that I noted below.
> diff --git a/datapath/flow.c b/datapath/flow.c
> index d07337c..49c0dd8 100644
> --- a/datapath/flow.c
> +++ b/datapath/flow.c
> @@ -1162,14 +1166,15 @@ int ovs_flow_from_nlattrs(struct sw_flow_key *swkey, int *key_lenp,
> * get the metadata, that is, the parts of the flow key that cannot be
> * extracted from the packet itself.
> */
> -int ovs_flow_metadata_from_nlattrs(u32 *priority, u16 *in_port, __be64 *tun_id,
> +int ovs_flow_metadata_from_nlattrs(u32 *priority, u16 *in_port,
> + struct ovs_key_ipv4_tunnel *tun_key,
> const struct nlattr *attr)
> {
> const struct nlattr *nla;
> int rem;
>
> *in_port = DP_MAX_PORTS;
> - *tun_id = 0;
> + tun_key->tun_id = 0;
I think we probably want to memset the entire tun_key to zero to avoid having potentially uninitialized data in the flow.
>
> @@ -1204,15 +1210,21 @@ int ovs_flow_metadata_from_nlattrs(u32 *priority, u16 *in_port, __be64 *tun_id,
> int ovs_flow_to_nlattrs(const struct sw_flow_key *swkey, struct sk_buff *skb)
> {
> struct ovs_key_ethernet *eth_key;
> + struct ovs_key_ipv4_tunnel *tun_key;
> struct nlattr *nla, *encap;
>
> if (swkey->phy.priority &&
> nla_put_u32(skb, OVS_KEY_ATTR_PRIORITY, swkey->phy.priority))
> goto nla_put_failure;
>
> - if (swkey->phy.tun_id != cpu_to_be64(0) &&
> - nla_put_be64(skb, OVS_KEY_ATTR_TUN_ID, swkey->phy.tun_id))
> - goto nla_put_failure;
> + if (swkey->phy.tun_key.ipv4_dst) {
It's probably OK to use DIP equal to zero as a not present marker but we need to enforce that it's always true - for example we shouldn't allow somebody to setup a flow that way or receive packets with a zero address. Alternately, we may be able to find a spare bit to indicate this, like is done with vlans.
In any case, I think we need to do some additional validation when setting up flows to check reserved space, for example, as otherwise that will never match.
> diff --git a/datapath/flow.h b/datapath/flow.h
> index 5be481e..bab5363 100644
> --- a/datapath/flow.h
> +++ b/datapath/flow.h
> @@ -42,7 +42,7 @@ struct sw_flow_actions {
>
> struct sw_flow_key {
> struct {
> - __be64 tun_id; /* Encapsulating tunnel ID. */
> + struct ovs_key_ipv4_tunnel tun_key; /* Encapsulating tunnel key. */
This is an optimization but as we get closer I'd like to put the tun_key at the end of struct sw_flow_key so that packets that didn't come from a tunnel don't have to pay the cost during the lookup (this is especially true as we add support for IPv6 tunnels).
In a similar vein, struct ovs_key_ipv4_tunnel contains some fields that I think can never apply for lookup such as the flags so it would be nice if we could remove that for lookup.
>
> @@ -150,6 +150,7 @@ u64 ovs_flow_used_time(unsigned long flow_jiffies);
> * ------ --- ------ -----
> * OVS_KEY_ATTR_PRIORITY 4 -- 4 8
> * OVS_KEY_ATTR_TUN_ID 8 -- 4 12
> + * OVS_KEY_ATTR_IPV4_TUNNEL 18 2 4 24
If my math is correct, I think the size of the base struct ova_key_ipv4_tunnel is 24 bytes.
> +static inline void tun_key_swap_addr(struct ovs_key_ipv4_tunnel *tun_key)
> +{
> + __be32 ndst = tun_key->ipv4_src;
> + tun_key->ipv4_src = tun_key->ipv4_dst;
> + tun_key->ipv4_dst = ndst;
> +}
I'm not quite sure when we would need to swap the addresses in a tunnel and I didn't see any uses of this function.
> +static inline void tun_key_init(struct ovs_key_ipv4_tunnel *tun_key,
> + const struct iphdr *iph, __be64 tun_id)
> +{
> + tun_key->tun_id = tun_id;
> + tun_key->ipv4_src = iph->saddr;
> + tun_key->ipv4_dst = iph->daddr;
> + tun_key->ipv4_tos = iph->tos;
> + tun_key->ipv4_ttl = iph->ttl;
> +}
>
Aren't there some fields that we need to zero out to avoid problems in the lookup?
> diff --git a/datapath/tunnel.c b/datapath/tunnel.c
> index d651c11..010e513 100644
> --- a/datapath/tunnel.c
> +++ b/datapath/tunnel.c
> @@ -367,9 +367,9 @@ struct vport *ovs_tnl_find_port(struct net *net, __be32 saddr, __be32 daddr,
> return NULL;
> }
>
> -static void ecn_decapsulate(struct sk_buff *skb, u8 tos)
> +static void ecn_decapsulate(struct sk_buff *skb)
> {
> - if (unlikely(INET_ECN_is_ce(tos))) {
> + if (unlikely(INET_ECN_is_ce(OVS_CB(skb)->tun_key->ipv4_tos))) {
> __be16 protocol = skb->protocol;
This might come in a later patch, although I didn't see it in a quick scan, but it should be possible to implement all the ECN encapsulation and decapsulation in userspace, just like we can do with the rest of the ToS and TTL.
>
> bool ovs_tnl_frag_needed(struct vport *vport,
> const struct tnl_mutable_config *mutable,
> - struct sk_buff *skb, unsigned int mtu, __be64 flow_key)
> + struct sk_buff *skb, unsigned int mtu,
> + struct ovs_key_ipv4_tunnel *tun_key)
> {
> unsigned int eth_hdr_len = ETH_HLEN;
> unsigned int total_length = 0, header_length = 0, payload_length;
> struct ethhdr *eh, *old_eh = eth_hdr(skb);
> struct sk_buff *nskb;
> + struct ovs_key_ipv4_tunnel ntun_key;
>
> /* Sanity check */
> if (skb->protocol == htons(ETH_P_IP)) {
> @@ -705,8 +707,10 @@ bool ovs_tnl_frag_needed(struct vport *vport,
> * any way of synthesizing packets.
> */
> if ((mutable->flags & (TNL_F_IN_KEY_MATCH | TNL_F_OUT_KEY_ACTION)) ==
> - (TNL_F_IN_KEY_MATCH | TNL_F_OUT_KEY_ACTION))
> - OVS_CB(nskb)->tun_id = flow_key;
> + (TNL_F_IN_KEY_MATCH | TNL_F_OUT_KEY_ACTION)) {
> + ntun_key = *tun_key;
> + OVS_CB(nskb)->tun_key = &ntun_key;
> + }
I guess this is probably where you were going to use the function to reverse IP addresses. The logic doesn't really work but it's moot since this is going away anyways.
>
> @@ -799,10 +803,8 @@ static void create_tunnel_header(const struct vport *vport,
> iph->ihl = sizeof(struct iphdr) >> 2;
> iph->frag_off = htons(IP_DF);
> iph->protocol = tnl_vport->tnl_ops->ipproto;
> - iph->tos = mutable->tos;
> iph->daddr = rt->rt_dst;
> iph->saddr = rt->rt_src;
> - iph->ttl = mutable->ttl;
> if (!iph->ttl)
> iph->ttl = ip4_dst_hoplimit(&rt_dst(rt));
>
I'm not sure that these changes quite belong in this patch (not that it shouldn't be done but it seems like the supporting code isn't there yet).
>
> diff --git a/datapath/vport-gre.c b/datapath/vport-gre.c
> index ab89c5b..fd2b038 100644
> --- a/datapath/vport-gre.c
> +++ b/datapath/vport-gre.c
> @@ -101,10 +101,6 @@ static struct sk_buff *gre_update_header(const struct vport *vport,
> __be32 *options = (__be32 *)(skb_network_header(skb) + mutable->tunnel_hlen
> - GRE_HEADER_SECTION);
>
> - /* Work backwards over the options so the checksum is last. */
> - if (mutable->flags & TNL_F_OUT_KEY_ACTION)
> - *options = be64_get_low32(OVS_CB(skb)->tun_id);
Why does this go away?
> diff --git a/datapath/vport.c b/datapath/vport.c
> index 172261a..0c77a1b 100644
> --- a/datapath/vport.c
> +++ b/datapath/vport.c
> @@ -462,7 +462,7 @@ void ovs_vport_receive(struct vport *vport, struct sk_buff *skb)
> OVS_CB(skb)->flow = NULL;
>
> if (!(vport->ops->flags & VPORT_F_TUN_ID))
> - OVS_CB(skb)->tun_id = 0;
> + OVS_CB(skb)->tun_key = NULL;
We probably should rename this flag now.
> diff --git a/lib/odp-util.h b/lib/odp-util.h
> index d53f083..4e5a8a1 100644
> --- a/lib/odp-util.h
> +++ b/lib/odp-util.h
> @@ -72,6 +72,7 @@ int odp_actions_from_string(const char *, const struct simap *port_names,
> * ------ --- ------ -----
> * OVS_KEY_ATTR_PRIORITY 4 -- 4 8
> * OVS_KEY_ATTR_TUN_ID 8 -- 4 12
> + * OVS_KEY_ATTR_IPV4_TUNNEL 18 2 4 24
Same thing about the size here as well.
[-- Attachment #1.2: Type: text/html, Size: 19171 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [ovs-dev] [PATCH 01/21] datapath: tunnelling: Replace tun_id with tun_key
From: Jesse Gross @ 2012-06-03 9:15 UTC (permalink / raw)
To: Simon Horman; +Cc: dev, netdev
In-Reply-To: <1337850554-10339-2-git-send-email-horms@verge.net.au>
On Thu, May 24, 2012 at 6:08 PM, Simon Horman <horms@verge.net.au> wrote:
> this is a first pass at providing a tun_key which can be used
> as the basis for flow-based tunnelling. The tun_key includes and
> replaces the tun_id in both struct ovs_skb_cb and struct sw_tun_key.
>
> In ovs_skb_cb tun_key is a pointer as it is envisaged that it will grow
> when support for IPv6 to an extent that inlining the structure will result
> in ovs_skb_cb being larger than the 48 bytes available in skb->cb.
>
> As OVS does not support IPv6 as the outer transport protocol for tunnels
> the IPv6 portions of this change, which appeared in the previous revision,
> have been dropped in order to limit the scope and size of this patch.
>
> This patch does not make any effort to retain the existing tun_id behaviour
> nor does it fully implement flow-based tunnels. As such it it is incomplete
> and can't be used in its current form (other than to break OVS tunnelling).
>
> ** Please do not apply **
>
> Cc: Kyle Mestery <kmestery@cisco.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>
Thanks and sorry again about being so slow to look at this.
Overall, this looks pretty good to me. The main difficulty that I had
was in figuring out what should go with the old behavior and what
should go with the new since it's at an intermediate point between the
two but I understand that it's difficult to break it up in a way that
both encapsulates a particular set of functionality and isn't too
large. Otherwise, I noticed a few specific things that I noted below.
> diff --git a/datapath/flow.c b/datapath/flow.c
> index d07337c..49c0dd8 100644
> --- a/datapath/flow.c
> +++ b/datapath/flow.c
> @@ -1162,14 +1166,15 @@ int ovs_flow_from_nlattrs(struct sw_flow_key *swkey, int *key_lenp,
> * get the metadata, that is, the parts of the flow key that cannot be
> * extracted from the packet itself.
> */
> -int ovs_flow_metadata_from_nlattrs(u32 *priority, u16 *in_port, __be64 *tun_id,
> +int ovs_flow_metadata_from_nlattrs(u32 *priority, u16 *in_port,
> + struct ovs_key_ipv4_tunnel *tun_key,
> const struct nlattr *attr)
> {
> const struct nlattr *nla;
> int rem;
>
> *in_port = DP_MAX_PORTS;
> - *tun_id = 0;
> + tun_key->tun_id = 0;
I think we probably want to memset the entire tun_key to zero to avoid
having potentially uninitialized data in the flow.
> @@ -1204,15 +1210,21 @@ int ovs_flow_metadata_from_nlattrs(u32 *priority, u16 *in_port, __be64 *tun_id,
> int ovs_flow_to_nlattrs(const struct sw_flow_key *swkey, struct sk_buff *skb)
> {
> struct ovs_key_ethernet *eth_key;
> + struct ovs_key_ipv4_tunnel *tun_key;
> struct nlattr *nla, *encap;
>
> if (swkey->phy.priority &&
> nla_put_u32(skb, OVS_KEY_ATTR_PRIORITY, swkey->phy.priority))
> goto nla_put_failure;
>
> - if (swkey->phy.tun_id != cpu_to_be64(0) &&
> - nla_put_be64(skb, OVS_KEY_ATTR_TUN_ID, swkey->phy.tun_id))
> - goto nla_put_failure;
> + if (swkey->phy.tun_key.ipv4_dst) {
It's probably OK to use DIP equal to zero as a not present marker but
we need to enforce that it's always true - for example we shouldn't
allow somebody to setup a flow that way or receive packets with a zero
address. Alternately, we may be able to find a spare bit to indicate
this, like is done with vlans.
In any case, I think we need to do some additional validation when
setting up flows to check reserved space, for example, as otherwise
that will never match.
> diff --git a/datapath/flow.h b/datapath/flow.h
> index 5be481e..bab5363 100644
> --- a/datapath/flow.h
> +++ b/datapath/flow.h
> @@ -42,7 +42,7 @@ struct sw_flow_actions {
>
> struct sw_flow_key {
> struct {
> - __be64 tun_id; /* Encapsulating tunnel ID. */
> + struct ovs_key_ipv4_tunnel tun_key; /* Encapsulating tunnel key. */
This is an optimization but as we get closer I'd like to put the
tun_key at the end of struct sw_flow_key so that packets that didn't
come from a tunnel don't have to pay the cost during the lookup (this
is especially true as we add support for IPv6 tunnels).
In a similar vein, struct ovs_key_ipv4_tunnel contains some fields
that I think can never apply for lookup such as the flags so it would
be nice if we could remove that for lookup.
> @@ -150,6 +150,7 @@ u64 ovs_flow_used_time(unsigned long flow_jiffies);
> * ------ --- ------ -----
> * OVS_KEY_ATTR_PRIORITY 4 -- 4 8
> * OVS_KEY_ATTR_TUN_ID 8 -- 4 12
> + * OVS_KEY_ATTR_IPV4_TUNNEL 18 2 4 24
If my math is correct, I think the size of the base struct
ova_key_ipv4_tunnel is 24 bytes.
> +static inline void tun_key_swap_addr(struct ovs_key_ipv4_tunnel *tun_key)
> +{
> + __be32 ndst = tun_key->ipv4_src;
> + tun_key->ipv4_src = tun_key->ipv4_dst;
> + tun_key->ipv4_dst = ndst;
> +}
I'm not quite sure when we would need to swap the addresses in a
tunnel and I didn't see any uses of this function.
> +static inline void tun_key_init(struct ovs_key_ipv4_tunnel *tun_key,
> + const struct iphdr *iph, __be64 tun_id)
> +{
> + tun_key->tun_id = tun_id;
> + tun_key->ipv4_src = iph->saddr;
> + tun_key->ipv4_dst = iph->daddr;
> + tun_key->ipv4_tos = iph->tos;
> + tun_key->ipv4_ttl = iph->ttl;
> +}
Aren't there some fields that we need to zero out to avoid problems in
the lookup?
> diff --git a/datapath/tunnel.c b/datapath/tunnel.c
> index d651c11..010e513 100644
> --- a/datapath/tunnel.c
> +++ b/datapath/tunnel.c
> @@ -367,9 +367,9 @@ struct vport *ovs_tnl_find_port(struct net *net, __be32 saddr, __be32 daddr,
> return NULL;
> }
>
> -static void ecn_decapsulate(struct sk_buff *skb, u8 tos)
> +static void ecn_decapsulate(struct sk_buff *skb)
> {
> - if (unlikely(INET_ECN_is_ce(tos))) {
> + if (unlikely(INET_ECN_is_ce(OVS_CB(skb)->tun_key->ipv4_tos))) {
This might come in a later patch, although I didn't see it in a quick
scan, but it should be possible to implement all the ECN encapsulation
and decapsulation in userspace, just like we can do with the rest of
the ToS and TTL.
> bool ovs_tnl_frag_needed(struct vport *vport,
> const struct tnl_mutable_config *mutable,
> - struct sk_buff *skb, unsigned int mtu, __be64 flow_key)
> + struct sk_buff *skb, unsigned int mtu,
> + struct ovs_key_ipv4_tunnel *tun_key)
> {
> unsigned int eth_hdr_len = ETH_HLEN;
> unsigned int total_length = 0, header_length = 0, payload_length;
> struct ethhdr *eh, *old_eh = eth_hdr(skb);
> struct sk_buff *nskb;
> + struct ovs_key_ipv4_tunnel ntun_key;
>
> /* Sanity check */
> if (skb->protocol == htons(ETH_P_IP)) {
> @@ -705,8 +707,10 @@ bool ovs_tnl_frag_needed(struct vport *vport,
> * any way of synthesizing packets.
> */
> if ((mutable->flags & (TNL_F_IN_KEY_MATCH | TNL_F_OUT_KEY_ACTION)) ==
> - (TNL_F_IN_KEY_MATCH | TNL_F_OUT_KEY_ACTION))
> - OVS_CB(nskb)->tun_id = flow_key;
> + (TNL_F_IN_KEY_MATCH | TNL_F_OUT_KEY_ACTION)) {
> + ntun_key = *tun_key;
> + OVS_CB(nskb)->tun_key = &ntun_key;
> + }
I guess this is probably where you were going to use the function to
reverse IP addresses. The logic doesn't really work but it's moot
since this is going away anyways.
> @@ -799,10 +803,8 @@ static void create_tunnel_header(const struct vport *vport,
> iph->ihl = sizeof(struct iphdr) >> 2;
> iph->frag_off = htons(IP_DF);
> iph->protocol = tnl_vport->tnl_ops->ipproto;
> - iph->tos = mutable->tos;
> iph->daddr = rt->rt_dst;
> iph->saddr = rt->rt_src;
> - iph->ttl = mutable->ttl;
> if (!iph->ttl)
> iph->ttl = ip4_dst_hoplimit(&rt_dst(rt));
I'm not sure that these changes quite belong in this patch (not that
it shouldn't be done but it seems like the supporting code isn't there
yet).
> diff --git a/datapath/vport-gre.c b/datapath/vport-gre.c
> index ab89c5b..fd2b038 100644
> --- a/datapath/vport-gre.c
> +++ b/datapath/vport-gre.c
> @@ -101,10 +101,6 @@ static struct sk_buff *gre_update_header(const struct vport *vport,
> __be32 *options = (__be32 *)(skb_network_header(skb) + mutable->tunnel_hlen
> - GRE_HEADER_SECTION);
>
> - /* Work backwards over the options so the checksum is last. */
> - if (mutable->flags & TNL_F_OUT_KEY_ACTION)
> - *options = be64_get_low32(OVS_CB(skb)->tun_id);
Why does this go away?
> diff --git a/datapath/vport.c b/datapath/vport.c
> index 172261a..0c77a1b 100644
> --- a/datapath/vport.c
> +++ b/datapath/vport.c
> @@ -462,7 +462,7 @@ void ovs_vport_receive(struct vport *vport, struct sk_buff *skb)
> OVS_CB(skb)->flow = NULL;
>
> if (!(vport->ops->flags & VPORT_F_TUN_ID))
> - OVS_CB(skb)->tun_id = 0;
> + OVS_CB(skb)->tun_key = NULL;
We probably should rename this flag now.
> diff --git a/lib/odp-util.h b/lib/odp-util.h
> index d53f083..4e5a8a1 100644
> --- a/lib/odp-util.h
> +++ b/lib/odp-util.h
> @@ -72,6 +72,7 @@ int odp_actions_from_string(const char *, const struct simap *port_names,
> * ------ --- ------ -----
> * OVS_KEY_ATTR_PRIORITY 4 -- 4 8
> * OVS_KEY_ATTR_TUN_ID 8 -- 4 12
> + * OVS_KEY_ATTR_IPV4_TUNNEL 18 2 4 24
Same thing about the size here as well.
^ permalink raw reply
* [README]: net-next is open...
From: David Miller @ 2012-06-03 17:36 UTC (permalink / raw)
To: netdev; +Cc: netfilter-devel, linux-wireless
With the 3.5-rc1 release, net-next is now open.
Bombs away...
^ permalink raw reply
* Generic user-space routing library -- need collaborator
From: Philip Prindeville @ 2012-06-03 19:39 UTC (permalink / raw)
To: Netdev
Hi.
I'm working on adding a few more portability classes to Poco (a multi-platform C++ toolkit) and wanted to add a Net::Routing class for examining and manipulating the routing tables.
The C++ would just be convenience wrappers around a core C library that handles the netlink semantics. I've looked at libmnl and it's handy, but I need a higher level of abstraction (for instance, parsing an RTA_NETMASK for IPv6 is anything but well-documented).
I'm running into the limits of my linux-specific knowledge, though. I can get a specific route, but not the non-specific (default) route. Unless I'm doing something wrong (and I may be), the only way to get the default route seems to be to either get a route to a host you know will never be in your routing table, or else to dump the entire table and grep it out.
Not sure if that's a shortcoming in the rtnetlink API or my being an idiot.
Maybe both.
Anyway, if anyone can walk me through parsing some of the more esoteric routing permutations (like 6to4 tunnels, etc) I'd appreciate their contacting me out-of-band.
Thanks,
-Philip
^ permalink raw reply
* Re: [Announce] LARTC wiki available
From: Philip Prindeville @ 2012-06-03 20:05 UTC (permalink / raw)
To: Niccolò Belli
Cc: lartc, netfilter@vger.kernel.org,
Linux Networking Developer Mailing List
In-Reply-To: <4EFB3B2B.7060200@linuxsystems.it>
On 12/28/11 8:52 AM, Niccolò Belli wrote:
> Hi,
> I still didn't find a viable solution for the LARTC wiki, so I decided
> to start hosting it on my own server. Later we can easily switch
> somewhere else if we keep using the same wiki engine (and maybe even
> with another wiki engine).
> I decided to use wikimedia because it's the only one I know of, so if
> someone knows a better alternative please let me know, we are still in
> time for a change.
> Since I never used a wiki seriously I will probably need someone else
> who can help me maintaining it, please let me know if you are
> experienced and willing to help.
>
> Here is the wiki: http://lartc.linuxsystems.it/
> And here is the new mailing list for those who still don't know:
> http://vger.kernel.org/vger-lists.html#lartc
>
> I just copy-pasted the Linux Advanced Routing & Traffic Control HOWTO
> atm, it still needs to be wikified and we still need to choose how to
> organize the contents.
>
> Cheers,
> Niccolò
Between command-line stuff for users/administrators and the kernel hacking bits on linux-net, etc. I'd like to see a middle ground: i.e. better documentation about the C API to userspace from the kernel routing mechanisms.
Better documentation about rtnetlink would be appreciated, and maybe the low-level libraries that run atop that as well, such as libmnl.
-Philip
^ permalink raw reply
* [PATCH] net/ethernet: ks8851_mll mac address configuration support added
From: Raffaele Recalcati @ 2012-06-03 20:43 UTC (permalink / raw)
To: netdev, David S. Miller, Alexey Dobriyan, Thomas Meyer; +Cc: Raffaele Recalcati
From: Raffaele Recalcati <raffaele.recalcati@bticino.it>
Signed-off-by: Raffaele Recalcati <raffaele.recalcati@bticino.it>
---
drivers/net/ethernet/micrel/ks8851_mll.c | 25 +++++++++++++++-------
include/linux/ks8851_mll.h | 33 ++++++++++++++++++++++++++++++
2 files changed, 51 insertions(+), 7 deletions(-)
create mode 100644 include/linux/ks8851_mll.h
diff --git a/drivers/net/ethernet/micrel/ks8851_mll.c b/drivers/net/ethernet/micrel/ks8851_mll.c
index 2784bc7..b9893b5 100644
--- a/drivers/net/ethernet/micrel/ks8851_mll.c
+++ b/drivers/net/ethernet/micrel/ks8851_mll.c
@@ -35,7 +35,7 @@
#include <linux/platform_device.h>
#include <linux/delay.h>
#include <linux/slab.h>
-#include <asm/io.h>
+#include <linux/ks8851_mll.h>
#define DRV_NAME "ks8851_mll"
@@ -1516,6 +1516,7 @@ static int __devinit ks8851_probe(struct platform_device *pdev)
struct net_device *netdev;
struct ks_net *ks;
u16 id, data;
+ struct ks8851_mll_platform_data *pdata;
io_d = platform_get_resource(pdev, IORESOURCE_MEM, 0);
io_c = platform_get_resource(pdev, IORESOURCE_MEM, 1);
@@ -1597,17 +1598,27 @@ static int __devinit ks8851_probe(struct platform_device *pdev)
ks_disable_qmu(ks);
ks_setup(ks);
ks_setup_int(ks);
- memcpy(netdev->dev_addr, ks->mac_addr, 6);
data = ks_rdreg16(ks, KS_OBCR);
ks_wrreg16(ks, KS_OBCR, data | OBCR_ODS_16MA);
- /**
- * If you want to use the default MAC addr,
- * comment out the 2 functions below.
- */
+ /* overwriting the default MAC address */
+ pdata = pdev->dev.platform_data;
+ if (!pdata) {
+ netdev_err(netdev, "No platform data\n");
+ err = -ENODEV;
+ goto err_register;
+ }
+ memcpy(ks->mac_addr, pdata->mac_addr, 6);
+ if (!is_valid_ether_addr(ks->mac_addr)) {
+ /* Use random MAC address if none passed */
+ random_ether_addr(ks->mac_addr);
+ netdev_info(netdev, "Using random mac address\n");
+ }
+ netdev_info(netdev, "Mac address is: %pM\n", ks->mac_addr);
+
+ memcpy(netdev->dev_addr, ks->mac_addr, 6);
- random_ether_addr(netdev->dev_addr);
ks_set_mac(ks, netdev->dev_addr);
id = ks_rdreg16(ks, KS_CIDER);
diff --git a/include/linux/ks8851_mll.h b/include/linux/ks8851_mll.h
new file mode 100644
index 0000000..e9ccfb5
--- /dev/null
+++ b/include/linux/ks8851_mll.h
@@ -0,0 +1,33 @@
+/*
+ * ks8861_mll platform data struct definition
+ * Copyright (c) 2012 BTicino S.p.A.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef _LINUX_KS8851_MLL_H
+#define _LINUX_KS8851_MLL_H
+
+#include <linux/if_ether.h>
+
+/**
+ * struct ks8851_mll_platform_data - Platform data of the KS8851_MLL network driver
+ * @macaddr: The MAC address of the device, set to all 0:s to use the on in
+ * the chip.
+ */
+struct ks8851_mll_platform_data {
+ u8 mac_addr[ETH_ALEN];
+};
+
+#endif
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/4] can: c_can: fix race condition in c_can_open()
From: Marc Kleine-Budde @ 2012-06-03 22:21 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-can, AnilKumar Ch, Marc Kleine-Budde
In-Reply-To: <1338762120-12695-1-git-send-email-mkl@pengutronix.de>
From: AnilKumar Ch <anilkumar@ti.com>
Fix the issue of C_CAN interrupts getting disabled forever when canconfig
utility is used multiple times. According to NAPI usage we disable all
the hardware interrupts in ISR and re-enable them in poll(). Current
implementation calls napi_enable() after hardware interrupts are enabled.
If we get any interrupts between these two steps then we do not process
those interrupts because napi is not enabled. Mostly these interrupts
come because of STATUS is not 0x7 or ERROR interrupts. If napi_enable()
happens before HW interrupts enabled then c_can_poll() function will be
called eventual re-enabling.
This patch moves the napi_enable() call before interrupts enabled.
Cc: stable@kernel.org # 2.6.39+
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/c_can/c_can.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index fa01621..8dc84d6 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -1064,10 +1064,11 @@ static int c_can_open(struct net_device *dev)
goto exit_irq_fail;
}
+ napi_enable(&priv->napi);
+
/* start the c_can controller */
c_can_start(dev);
- napi_enable(&priv->napi);
netif_start_queue(dev);
return 0;
--
1.7.4.1
^ permalink raw reply related
* [PATCH 4/4] can: cc770: Fix likely misuse of | for &
From: Marc Kleine-Budde @ 2012-06-03 22:22 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-can, Joe Perches, Marc Kleine-Budde
In-Reply-To: <1338762120-12695-1-git-send-email-mkl@pengutronix.de>
From: Joe Perches <joe@perches.com>
Using | with a constant is always true.
Likely this should have be &.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/cc770/cc770_platform.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/can/cc770/cc770_platform.c b/drivers/net/can/cc770/cc770_platform.c
index 53115ee..688371c 100644
--- a/drivers/net/can/cc770/cc770_platform.c
+++ b/drivers/net/can/cc770/cc770_platform.c
@@ -154,7 +154,7 @@ static int __devinit cc770_get_platform_data(struct platform_device *pdev,
struct cc770_platform_data *pdata = pdev->dev.platform_data;
priv->can.clock.freq = pdata->osc_freq;
- if (priv->cpu_interface | CPUIF_DSC)
+ if (priv->cpu_interface & CPUIF_DSC)
priv->can.clock.freq /= 2;
priv->clkout = pdata->cor;
priv->bus_config = pdata->bcr;
--
1.7.4.1
^ permalink raw reply related
* pull-request: can 2012-06-03
From: Marc Kleine-Budde @ 2012-06-03 22:21 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-can
Hello David,
here is a series of patches intended for v3.5, targeting net/master.
The first three patches are by AnilKumar Ch and fix problems in the c_can
driver. While extending the c_can driver for the Bosch's d_can hardware
he found three problems in the existing driver: first a race condition in
the open() function, second a interrupt thrashing issue and third a
off-by-one when looking for transmitted packets.
The fourth patch is by Joe Perches, it fixes a misuse of | for & in the
cc770 driver.
regards, Marc
---
The following changes since commit 9ca3cc6f3026946ba655e863ca2096339e667639:
fec_mpc52xx: fix timestamp filtering (2012-06-02 17:09:08 -0400)
are available in the git repository at:
git@gitorious.org:linux-can/linux-can.git master
AnilKumar Ch (3):
can: c_can: fix "BUG! echo_skb is occupied!" during transmit
can: c_can: fix an interrupt thrash issue with c_can driver
can: c_can: fix race condition in c_can_open()
Joe Perches (1):
can: cc770: Fix likely misuse of | for &
drivers/net/can/c_can/c_can.c | 16 +++++++++-------
drivers/net/can/c_can/c_can.h | 1 +
drivers/net/can/cc770/cc770_platform.c | 2 +-
3 files changed, 11 insertions(+), 8 deletions(-)
^ permalink raw reply
* [PATCH 2/4] can: c_can: fix an interrupt thrash issue with c_can driver
From: Marc Kleine-Budde @ 2012-06-03 22:21 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-can, AnilKumar Ch, Marc Kleine-Budde
In-Reply-To: <1338762120-12695-1-git-send-email-mkl@pengutronix.de>
From: AnilKumar Ch <anilkumar@ti.com>
This patch fixes an interrupt thrash issue with c_can driver.
In c_can_isr() function interrupts are disabled and enabled only in
c_can_poll() function. c_can_isr() & c_can_poll() both read the
irqstatus flag. However, irqstatus is always read as 0 in c_can_poll()
because all C_CAN interrupts are disabled in c_can_isr(). This causes
all interrupts to be re-enabled in c_can_poll() which in turn causes
another interrupt since the event is not really handled. This keeps
happening causing a flood of interrupts.
To fix this, read the irqstatus register in isr and use the same cached
value in the poll function.
Cc: stable@kernel.org # 2.6.39+
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/c_can/c_can.c | 7 +++----
drivers/net/can/c_can/c_can.h | 1 +
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 9ac28df..fa01621 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -952,7 +952,7 @@ static int c_can_poll(struct napi_struct *napi, int quota)
struct net_device *dev = napi->dev;
struct c_can_priv *priv = netdev_priv(dev);
- irqstatus = priv->read_reg(priv, &priv->regs->interrupt);
+ irqstatus = priv->irqstatus;
if (!irqstatus)
goto end;
@@ -1030,12 +1030,11 @@ end:
static irqreturn_t c_can_isr(int irq, void *dev_id)
{
- u16 irqstatus;
struct net_device *dev = (struct net_device *)dev_id;
struct c_can_priv *priv = netdev_priv(dev);
- irqstatus = priv->read_reg(priv, &priv->regs->interrupt);
- if (!irqstatus)
+ priv->irqstatus = priv->read_reg(priv, &priv->regs->interrupt);
+ if (!priv->irqstatus)
return IRQ_NONE;
/* disable all interrupts and schedule the NAPI */
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 9b7fbef..5f32d34 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -76,6 +76,7 @@ struct c_can_priv {
unsigned int tx_next;
unsigned int tx_echo;
void *priv; /* for board-specific data */
+ u16 irqstatus;
};
struct net_device *alloc_c_can_dev(void);
--
1.7.4.1
^ permalink raw reply related
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