* Re: [PATCH ipsec v2 3/3] xfrm: choose protocol family by skb protocol
From: Hannes Frederic Sowa @ 2013-08-18 16:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, steffen.klassert, edumazet
In-Reply-To: <1376840901.21329.47.camel@edumazet-glaptop>
On Sun, Aug 18, 2013 at 08:48:21AM -0700, Eric Dumazet wrote:
> On Sun, 2013-08-18 at 13:47 +0200, Hannes Frederic Sowa wrote:
> > We need to choose the protocol family by skb->protocol. Otherwise we
> > call the wrong xfrm{4,6}_local_error handler in case an ipv6 sockets is
> > used in ipv4 mode, in which case we should call down to xfrm4_local_error
> > (ip6 sockets are a superset of ip4 ones).
> >
> > We are called before before ip_output functions, so skb->protocol is
> > not reset.
> >
> > v2:
> > a) unchanged
> >
> > Cc: Steffen Klassert <steffen.klassert@secunet.com>
> > Acked-by: Eric Dumazet <edumazet@google.com>
> > Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > ---
>
> Hi Hannes
>
> For your next patches, please add the v1/v2/v3 stuff _after_ the ---
> separator as in :
>
> Normal changelog (will be included in git history)
>
> Signed-off-by: ....
> Cc: ...
> ---
> v2: Fix (you can omit this line if there was no change between v2 and
> v1)
> diffstat
> diff
>
>
> This is to have clean changelogs, with high S/N ratio ;)
Of course, I can do so.
Actually, I thought having the changelog in the commit msg is an extra
plus (even it is mostly inexpressive) because one knows there could be
more than one thread on the mailing list regarding the commit.
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH v5 1/2] ARM: davinci: da850: add DT node for ethernet
From: Sekhar Nori @ 2013-08-18 16:55 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Lad, Prabhakar, DLOS, netdev, devicetree, LKML, linux-arm-kernel
In-Reply-To: <520E7377.1080808@cogentembedded.com>
On 8/17/2013 12:16 AM, Sergei Shtylyov wrote:
> Hello.
>
> On 08/16/2013 06:11 PM, Lad, Prabhakar wrote:
>
>> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
>> Add ethernet device tree node information and pinmux for mii to da850 by
>> providing interrupt details and local mac address.
>
>> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
>> ---
>> arch/arm/boot/dts/da850-evm.dts | 5 +++++
>> arch/arm/boot/dts/da850.dtsi | 30 ++++++++++++++++++++++++++++++
>> 2 files changed, 35 insertions(+)
>
>> diff --git a/arch/arm/boot/dts/da850-evm.dts
>> b/arch/arm/boot/dts/da850-evm.dts
>> index 1f8cfdd..44f3fbc 100644
>> --- a/arch/arm/boot/dts/da850-evm.dts
>> +++ b/arch/arm/boot/dts/da850-evm.dts
>> @@ -96,6 +96,11 @@
>> pinctrl-0 = <&mdio_pins>;
>> bus_freq = <2200000>;
>> };
>> + ethernet: emac@1e20000 {
>
> Why label the node in the board file too?
May be not required, but all other entries in da850-evm.dts have labels
too. Other .dts files like am335x-bone.dts use labels too (even though
they are never used in references). So I am inclined to let this be like
this and if needed have all the labels removed through a separate patch
- at least we remain consistent within the file that way.
Prabhakar,
Please mind the new e-mail address of the devicetree list.
Thanks,
Sekhar
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Corey Hickey @ 2013-08-18 16:59 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Netdev List, netfilter-devel
In-Reply-To: <1376839467.21329.36.camel@edumazet-glaptop>
On 2013-08-18 08:24, Eric Dumazet wrote:
> This looks like the bug we had to fix recently :
>
> http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=356d7d88e088687b6578ca64601b0a2c9d145296
>
> Could you try latest net tree ?
Thanks, I will do so, hopefully this evening (busy today).
-Corey
^ permalink raw reply
* Re: [PATCH 6/7] net: add the AF_FLEXRAY protocol
From: Oliver Hartkopp @ 2013-08-18 18:50 UTC (permalink / raw)
To: Benedikt Spranger; +Cc: netdev, Alexander Frank, Sebastian Andrzej Siewior
In-Reply-To: <1376384922-8519-8-git-send-email-b.spranger@linutronix.de>
On 13.08.2013 11:08, Benedikt Spranger wrote:
> FlexRay is a networking technology used in automotive fields as
> successor of the Controller Area Network (CAN). It provides the
> core functionality and a RAW protocol driver.
>
> Signed-off-by: Benedikt Spranger <b.spranger@linutronix.de>
Hello Benedikt,
first thanks for picking this FlexRay topic together with Eberspaecher.
There was a first attempt getting FlexRay into mainline by Michael Arndt:
http://www.scriptkiller.de/en/c27/computer_electronics/linux/flexray_4_linux/
You probably know that implementation too - it has a nice FlexRay Linux Logo.
My comment on that former implementation was if AF_FLEXRAY is really needed or
if a PF_PACKET socket would make it too.
I think to have the local echo of frames and if you intend to add the FlexRay
specific transport protocol it would make sense to create an AF_FLEXRAY.
The ISO15765-2 implementation would be a good starting point then:
https://gitorious.org/linux-can/can-modules/blobs/master/net/can/isotp.c
Some general remarks to your patch series:
- please write FlexRay and not Flexray in the comments
- patch 4/7 creates
include/linux/eray.h | 650 +++++++++++++++++++++++++
include/linux/flexcard.h | 95 ++++
include/uapi/linux/eray.h | 34 ++
include/uapi/linux/flexcard.h | 429 +++++++++++++++++
I wonder, if this header pollution is really needed on this level
E.g. eray.h could go into drivers/net/flexray/eray/eray.h ...
- It's not clear where flexcard begins and what is part of the Eray IP core.
I would suggest to have a Eray core driver (like we have the SJA1000 at CAN)
and create some Flexcard specific glue code to access the Eray core.
E.g. there is surely other HW available that uses the Eray core, right?
You have a clear separation from the Flexcard to the D_CAN controller too.
- Why do you need a
> include/uapi/linux/flexray/flexcard_netlink.h | 53 +++
???
Please try to find a generic approach that fits for all FlexRay hardware.
- some remarks on the file headers:
- Better write Eberspaecher than EberspÀcher which fits their website :-)
- there's no License information in the header
- a reference that this code is based on the CAN code is appropriate
- struct can_frame cf -> struct flexray_frame ff (you should rename the cf's)
I built your patches on the latest 3.11-rc5. Are there any simple tools to
play with the vflexray created devices, like candump or cansend for CAN?
> include/linux/flexray.h | 168 ++++++++
Looks good.
How are the FlexRay real-time requirements handled?
Is this done by the Eray core?
Best regards,
Oliver
^ permalink raw reply
* [PATCH net] net-packet: restore packet statistics tp_packets to include drops
From: Willem de Bruijn @ 2013-08-18 19:58 UTC (permalink / raw)
To: davem, dborkman, netdev; +Cc: Willem de Bruijn
getsockopt PACKET_STATISTICS returns tp_packets + tp_drops.
Commit ee80fbf301 cleaned up the getsockopt PACKET_STATISTICS code.
This also changed semantics. Historically, tp_packets included
tp_drops on return. The commit removed the line that adds tp_drops
into tp_packets.
This patch reinstates the old semantics.
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
net/packet/af_packet.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 4b66c75..75c8bbf 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -3259,9 +3259,11 @@ static int packet_getsockopt(struct socket *sock, int level, int optname,
if (po->tp_version == TPACKET_V3) {
lv = sizeof(struct tpacket_stats_v3);
+ st.stats3.tp_packets += st.stats3.tp_drops;
data = &st.stats3;
} else {
lv = sizeof(struct tpacket_stats);
+ st.stats1.tp_packets += st.stats1.tp_drops;
data = &st.stats1;
}
--
1.8.3
^ permalink raw reply related
* Re: Fwd: RFC 6980 on Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery
From: Loganaden Velvindron @ 2013-08-18 20:52 UTC (permalink / raw)
To: Loganaden Velvindron, Fernando Gont, netdev
In-Reply-To: <20130815102507.GA24122@order.stressinduktion.org>
On Thu, Aug 15, 2013 at 2:25 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
>
> On Thu, Aug 15, 2013 at 02:14:46PM +0400, Loganaden Velvindron wrote:
> > I'm not sure if you got my previous mails, but I'd like to know a
> > couple of things:
>
> Ah, you asked me off-list. So, for a wider audience, I copy & paste my answers
> from the just answered mail. ;)
>
> > 1) How can I test this diff ?
>
> Actually, nothing should change at all.
>
> Myself, I used scapy to construct some packets and send it to a system
> with the patched kernel and had some printks sprinkeled in the source
> while watching tcpdump.
>
> > 2) It's developed against which git brach ? linux-next ?
>
> Yes, I targeted linux-next. But it should apply to older kernels
> without too much fuzz as well.
>
I've tested with linux-next.
> > 3) What will/could break with this diff in a production environment ?
>
> RA messages could get fragmented if a speaker puts lots of options in it. I
> hope all RA speakers already spread the options over multiple RAs, but I don't
> know. In case the RA is fragmented it will now be dropped silently.
>
My IPv6 gateway machine runs OpenBSD, and so far, no issues with it.
I'm going to test
it at work in a couple of hours and report back.
> Thanks,
>
> Hannes
>
--
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.
^ permalink raw reply
* Re: [OpenWrt-Devel] [RFC][PATCH 2/2] bgmac: pass received packet to the netif instead of copying it
From: Rafał Miłecki @ 2013-08-18 21:06 UTC (permalink / raw)
To: Felix Fietkau
Cc: OpenWrt Development List, Network Development, Hauke Mehrtens,
Florian Fainelli, Jonas Gorski, Robert Bradley
In-Reply-To: <CACna6rwi1+2ghyyKonaw=6xVDwipb3=1zUzOJ7dVoNoVyRx9fw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6730 bytes --]
I performed some tests using Netgear WNDR4500 (BCM4706 based) using:
WNDR4500-V1.0.1.36_1.0.63.chk
On IRC we were wondering if switch does routing for the CPU, so I did
some trivial tests using "ifconfig".
Short introduction of available intefaces:
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.204e7fab3aa8 no vlan1
eth1
eth2
So br0 bridge connects: vlan1, eth1, eth2. I don't really know why
there are eth2 and vlan2
I was using 192.168.5.2 for my WAN port
I was using 192.168.1.1 for my LAN ports
192.168.5.1 was a "gate" PC with iperf -s running. On my 192.168.1.X
machine I started iperf -c. So it was transfer of packets from LAN
vlan to WAN vlan.
iperf.exe -c 192.168.5.1 -t 60
------------------------------------------------------------
Client connecting to 192.168.5.1, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.3 port 55244 connected with 192.168.5.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.0 sec 4.02 GBytes 576 Mbits/sec
As you can see, I got ~500Mb/s in comparison to ~105Mb/s when using OpenWrt.
Now the most interesting part (I hope my mailer won't fail on formatting):
# ifconfig; sleep 10; ifconfig
br0 Link encap:Ethernet HWaddr 11:22:33:44:55:A8
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::224e:7fff:feab:3aa8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3639 errors:0 dropped:0 overruns:0 frame:0
TX packets:4001 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:368045 (359.4 KiB) TX bytes:3516213 (3.3 MiB)
eth0 Link encap:Ethernet HWaddr 11:22:33:44:55:A9
inet addr:192.168.5.2 Bcast:192.168.5.255 Mask:255.255.255.0
inet6 addr: fe80::224e:7fff:feab:3aa9/64 Scope:Link
UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:309084 errors:0 dropped:0 overruns:0 frame:0
TX packets:3126985 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:19789406 (18.8 MiB) TX bytes:377801895 (360.2 MiB)
Interrupt:4 Base address:0x2000
eth1 Link encap:Ethernet HWaddr 11:22:33:44:55:A8
inet6 addr: fe80::224e:7fff:feab:3aa8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:424
TX packets:0 errors:65 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:3 Base address:0x8000
eth2 Link encap:Ethernet HWaddr 11:22:33:44:55:A7
inet6 addr: fe80::224e:7fff:feab:3aa7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:54 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:5 Base address:0x8000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MULTICAST MTU:16436 Metric:1
RX packets:107 errors:0 dropped:0 overruns:0 frame:0
TX packets:107 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:11408 (11.1 KiB) TX bytes:11408 (11.1 KiB)
vlan1 Link encap:Ethernet HWaddr 11:22:33:44:55:A8
inet6 addr: fe80::224e:7fff:feab:3aa8/64 Scope:Link
UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:3127849 errors:0 dropped:0 overruns:0 frame:0
TX packets:310049 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:390393723 (372.3 MiB) TX bytes:20643844 (19.6 MiB)
vlan2 Link encap:Ethernet HWaddr 11:22:33:44:55:A8
inet6 addr: fe80::224e:7fff:feab:3aa8/64 Scope:Link
UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
br0 Link encap:Ethernet HWaddr 11:22:33:44:55:A8
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::224e:7fff:feab:3aa8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3670 errors:0 dropped:0 overruns:0 frame:0
TX packets:4004 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:370146 (361.4 KiB) TX bytes:3516858 (3.3 MiB)
eth0 Link encap:Ethernet HWaddr 11:22:33:44:55:A9
inet addr:192.168.5.2 Bcast:192.168.5.255 Mask:255.255.255.0
inet6 addr: fe80::224e:7fff:feab:3aa9/64 Scope:Link
UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:362946 errors:0 dropped:0 overruns:0 frame:0
TX packets:3671812 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:23236574 (22.1 MiB) TX bytes:1191974445 (1.1 GiB)
Interrupt:4 Base address:0x2000
eth1 Link encap:Ethernet HWaddr 11:22:33:44:55:A8
inet6 addr: fe80::224e:7fff:feab:3aa8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:424
TX packets:0 errors:65 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:3 Base address:0x8000
eth2 Link encap:Ethernet HWaddr 11:22:33:44:55:A7
inet6 addr: fe80::224e:7fff:feab:3aa7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:54 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:5 Base address:0x8000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MULTICAST MTU:16436 Metric:1
RX packets:119 errors:0 dropped:0 overruns:0 frame:0
TX packets:119 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:12532 (12.2 KiB) TX bytes:12532 (12.2 KiB)
vlan1 Link encap:Ethernet HWaddr 11:22:33:44:55:A8
inet6 addr: fe80::224e:7fff:feab:3aa8/64 Scope:Link
UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:3672697 errors:0 dropped:0 overruns:0 frame:0
TX packets:363914 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1206747346 (1.1 GiB) TX bytes:24091669 (22.9 MiB)
vlan2 Link encap:Ethernet HWaddr 11:22:33:44:55:A8
inet6 addr: fe80::224e:7fff:feab:3aa8/64 Scope:Link
UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
So over 10s Netgear's firmware received ~700MiB of packets on vlan1
And it transferred ~700MiB of packets to eth0.
I believe it proves that Netgear's firmware doesn't use any built in
routing feature of the BCM53125 switch.
[-- Attachment #2: netgear.wndr4500.orig.firmware.ifconfig.txt --]
[-- Type: text/plain, Size: 6423 bytes --]
# ifconfig; sleep 10; ifconfig
br0 Link encap:Ethernet HWaddr 11:22:33:44:55:A8
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::224e:7fff:feab:3aa8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3639 errors:0 dropped:0 overruns:0 frame:0
TX packets:4001 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:368045 (359.4 KiB) TX bytes:3516213 (3.3 MiB)
eth0 Link encap:Ethernet HWaddr 11:22:33:44:55:A9
inet addr:192.168.5.2 Bcast:192.168.5.255 Mask:255.255.255.0
inet6 addr: fe80::224e:7fff:feab:3aa9/64 Scope:Link
UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:309084 errors:0 dropped:0 overruns:0 frame:0
TX packets:3126985 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:19789406 (18.8 MiB) TX bytes:377801895 (360.2 MiB)
Interrupt:4 Base address:0x2000
eth1 Link encap:Ethernet HWaddr 11:22:33:44:55:A8
inet6 addr: fe80::224e:7fff:feab:3aa8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:424
TX packets:0 errors:65 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:3 Base address:0x8000
eth2 Link encap:Ethernet HWaddr 11:22:33:44:55:A7
inet6 addr: fe80::224e:7fff:feab:3aa7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:54 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:5 Base address:0x8000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MULTICAST MTU:16436 Metric:1
RX packets:107 errors:0 dropped:0 overruns:0 frame:0
TX packets:107 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:11408 (11.1 KiB) TX bytes:11408 (11.1 KiB)
vlan1 Link encap:Ethernet HWaddr 11:22:33:44:55:A8
inet6 addr: fe80::224e:7fff:feab:3aa8/64 Scope:Link
UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:3127849 errors:0 dropped:0 overruns:0 frame:0
TX packets:310049 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:390393723 (372.3 MiB) TX bytes:20643844 (19.6 MiB)
vlan2 Link encap:Ethernet HWaddr 11:22:33:44:55:A8
inet6 addr: fe80::224e:7fff:feab:3aa8/64 Scope:Link
UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
br0 Link encap:Ethernet HWaddr 11:22:33:44:55:A8
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::224e:7fff:feab:3aa8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3670 errors:0 dropped:0 overruns:0 frame:0
TX packets:4004 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:370146 (361.4 KiB) TX bytes:3516858 (3.3 MiB)
eth0 Link encap:Ethernet HWaddr 11:22:33:44:55:A9
inet addr:192.168.5.2 Bcast:192.168.5.255 Mask:255.255.255.0
inet6 addr: fe80::224e:7fff:feab:3aa9/64 Scope:Link
UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:362946 errors:0 dropped:0 overruns:0 frame:0
TX packets:3671812 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:23236574 (22.1 MiB) TX bytes:1191974445 (1.1 GiB)
Interrupt:4 Base address:0x2000
eth1 Link encap:Ethernet HWaddr 11:22:33:44:55:A8
inet6 addr: fe80::224e:7fff:feab:3aa8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:424
TX packets:0 errors:65 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:3 Base address:0x8000
eth2 Link encap:Ethernet HWaddr 11:22:33:44:55:A7
inet6 addr: fe80::224e:7fff:feab:3aa7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:54 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:5 Base address:0x8000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MULTICAST MTU:16436 Metric:1
RX packets:119 errors:0 dropped:0 overruns:0 frame:0
TX packets:119 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:12532 (12.2 KiB) TX bytes:12532 (12.2 KiB)
vlan1 Link encap:Ethernet HWaddr 11:22:33:44:55:A8
inet6 addr: fe80::224e:7fff:feab:3aa8/64 Scope:Link
UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:3672697 errors:0 dropped:0 overruns:0 frame:0
TX packets:363914 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1206747346 (1.1 GiB) TX bytes:24091669 (22.9 MiB)
vlan2 Link encap:Ethernet HWaddr 11:22:33:44:55:A8
inet6 addr: fe80::224e:7fff:feab:3aa8/64 Scope:Link
UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
^ permalink raw reply
* Re: [PATCH net-next 2/2] bnx2x: add RSS capability for GRE traffic
From: Jerry Chu @ 2013-08-18 21:11 UTC (permalink / raw)
To: Eric Dumazet
Cc: Dmitry Kravkov, Dmitry Kravkov, davem@davemloft.net,
netdev@vger.kernel.org, Eilon Greenstein, Tom Herbert,
Maciej Żenczykowski, Uday Naik, Michael Dalton
In-Reply-To: <1376840262.21329.40.camel@edumazet-glaptop>
+mwdalton, uday
On Sun, Aug 18, 2013 at 8:37 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sun, 2013-08-18 at 04:55 -0700, Jerry Chu wrote:
>> On Sat, Aug 17, 2013 at 12:01 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > On Sat, 2013-08-17 at 21:52 +0300, Dmitry Kravkov wrote:
>> >
>> >>
>> >> Current bnx2x HW is not able to perform CSUM validation for
>> >> encapsulated packets, so in any case host needs to do that.
>> >> Today GRO/TPA feature depends on CSUM, but theoretically (i did not
>> >> investigate it) and probably HW can provide aggregated packets w/o
>> >> csum validation - this will save headers processing for host.
>> >
>> > I am not sure I understand this.
>> >
>> > Aggregation cannot be done if csums are not validated.
>>
>> Unless all the csums from aggregated pkts are also aggregated into one
>> (so that the host computes s/w csum on the large pkt and validates against
>> the aggregated csum...) There may be some performance benefit for doing
>> this but it may arguably weaken already weak 1's complement csum.
>
> To aggregate two packets, you first have to make sure the checksums of
> each packet are ok. If the hardware does not validate checksum, then it
> cannot aggregate packets.
It can if the csum validation is deferred. But this requires the stack code to
aggregate csum from individual pkt header, which can get ugly as one needs
to remove the header part from the individual csum first. It may also weaken
the already weak TCP csum as i mentioned previously. Also one corrupted
pkt will cause the whole GRO pkt to be thrown away. But I won't worry about
it for the data center environment where pkt corruption is rare.
>
> Sure, CHECKSUM_COMPLETE support would be nice, so that linux can perform
> aggregation without having to bring into cpu cache the whole frame.
I wish CHECKSUM_COMPLETE can be supported by the h/w - we are currently
running an older kernel w/o RSS for GRE support so all the GRE traffic between
two IPs hits the same NIC queue. With my GRO-GRE patch (to be upstreamed
later) I'm 20% below line rate (7.1Gbps) on 10GbE multi-TCP stream test because
RSS will saturate a single CPU that is handling softirq. The majority
of CPU cost
was from bcopy (~20%) followed by csum computation (4%). If I comment out the
csum validation in the GRO code then I hit line rate (9.1Gbps) right away on the
same test.
In order for me to saturate the line rate but without h/w CHECKSUM_COMPLETE
support, one other alternative is to back port the RSS for GRE support, which
seems a daunting task (if not please tell me). If I defer the csum
validation after
GRO then RPS will spread out traffic and the csum cost so we are no longer
bottlenecked on one CPU (and hopefully hit the line rate).
Jerry
>
>
>
^ permalink raw reply
* Re: [PATCH v3] r8169: fix invalid register dump
From: Francois Romieu @ 2013-08-18 21:21 UTC (permalink / raw)
To: Peter Wu; +Cc: Ben Hutchings, netdev, nic_swsd
In-Reply-To: <1376833298-7321-1-git-send-email-lekensteyn@gmail.com>
Peter Wu <lekensteyn@gmail.com> :
[...]
> check"[1]. I do not have sis190 hardware, but since that is based on
> this r8169 driver, would it make sense to apply this patch to sis190
> too?
Yes for the _REGS_SIZE part. Nobody proved that the memcpy_fromio split
is needed or even useful with a sis19x.
--
Ueimor
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Jozsef Kadlecsik @ 2013-08-18 21:23 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Corey Hickey, Linux Netdev List, netfilter-devel
In-Reply-To: <1376839467.21329.36.camel@edumazet-glaptop>
On Sun, 18 Aug 2013, Eric Dumazet wrote:
> On Sat, 2013-08-17 at 22:55 -0700, Corey Hickey wrote:
> > Hi,
> >
> > If there is a better user-oriented list I should ask this question on,
> > please tell me; I've asked a couple similar questions on netdev before
> > and gotten some great help.
> >
> >
> > I'm having a problem wherein some NATted connections stop forwarding
> > packets. I've troubleshot the problem far enough to tell that it happens
> > when path MTU discovery happens--the ACK to the retransmitted packet
> > never gets forwarded back to my local client (and neither do the
> > retransmitted ACKs).
> >
> > This is my setup:
> > ----------------------------------------------------------------------
> > MTU 9100 MTU 1355 MTU 1500
> > client --> linux router --> vpn --> work host
> > 198.18.0.3 198.18.0.1 (eth0) 10.15.24.13
> > 192.168.61.54 (tun0)
> > ----------------------------------------------------------------------
> >
> > I'm running openconnect on a Linux router to connect to a cisco VPN at
> > work. The Linux router does SNAT (MASQUERADE) over the virtual tun0
> > interface created by openconnect.
> >
> > This is the best test I have so far:
> >
> > $ sudo ip route flush cache ; ssh workhost.example.com exit
> > Read from socket failed: Connection reset by peer
> >
> > Most of the time, this hangs for a few minutes before giving up;
> > sometimes it just works fine. tcpdumps indicate that when it works, all
> > packets transmitted are below the VPN's MTU; when it fails, MTU
> > discovery has happened:
> >
> > 1. client sends large packet, for example 1832 bytes
> > 2. router sends ICMP fragmentation needed
> > 3. client retransmits with a smaller packet, for example 1303 bytes
> > 4. router forwards packet over VPN
> > 5. work host ACKs packet
> > 6. router receives ACK but does not forward it
> > 7. both endpoints retransmit, but ACKs never get forwarded
> >
> > The NAT table maintains an entry throughout (and continues to SNAT
> > retransmits from the client), but the ACKs from the server never get
> > forwarded.
> >
> > fire:~# netstat-nat -n -d 10.15.24.13
> > Proto NATed Address Destination Address State
> > tcp 198.18.0.3:51076 10.15.24.13:22 ESTABLISHED
> >
> >
> > I put a LOG target on the INPUT chain, though, and apparently these
> > packets are bypassing the NAT; the kernel does not think they should be
> > forwarded (else they would be on the FORWARD chain).
> >
> > [23335.509084] IN=tun0 OUT= MAC= SRC=10.15.24.13 DST=192.168.61.54
> > LEN=64 TOS=0x00 PREC=0x00 TTL=62 ID=28270 DF PROTO=TCP SPT=22 DPT=51076
> > WINDOW=134 RES=0x00 ACK FIN URGP=0
> >
> >
> > The kernel on the router is 3.10-2-amd64 (from Debian testing). I had
> > the same problem with 3.2.0-4-amd64 (from Debian stable), before I tried
> > to see if I could upgrade the problem away.
> >
> > Any help would be much appreciated. I can send full tcpdumps if needed.
>
> This looks like the bug we had to fix recently :
>
> http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=356d7d88e088687b6578ca64601b0a2c9d145296
>
> Could you try latest net tree ?
It's a PMTU related problem, so I'd suggest to check first the next ones:
Aren't the ICMP error messages (i.e. fragmentation-needed) filtered out?
If not, does adding an explicit TCPMSS rule to the mangle table help?
Isn't there SACK options involved? Maybe there's a "smart" sequence
number "anonymizer" device in the path which forgets about the SEQ numbers
in the SACK options and thus such packets are marked as INVALID.
So tcpdumps captured at both sides could really help to tell what goes wrong.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply
* Re: [PATCH net-next 2/2] bnx2x: add RSS capability for GRE traffic
From: Eric Dumazet @ 2013-08-18 23:44 UTC (permalink / raw)
To: Jerry Chu
Cc: Dmitry Kravkov, Dmitry Kravkov, davem@davemloft.net,
netdev@vger.kernel.org, Eilon Greenstein, Tom Herbert,
Maciej Żenczykowski, Uday Naik, Michael Dalton
In-Reply-To: <CAPshTCjB9S-Xc4MTs5XXLm6N=0-v_9gxC2SDwCzieTc4Py43fg@mail.gmail.com>
On Sun, 2013-08-18 at 14:11 -0700, Jerry Chu wrote:
> It can if the csum validation is deferred. But this requires the stack code to
> aggregate csum from individual pkt header, which can get ugly as one needs
> to remove the header part from the individual csum first.
You can _not_ aggregate packets _before_ validating their checksum, or
else you could end up with a correct final checksum while two or more
segments had buggy checksums. Checksum are already quite weak, please
do not make them even weaker ;)
GRO should not throw out any segments, it is not its role.
If a router receives a bunch of packets, it should forward them
regardless of the (TCP) checksum being good or not.
The final receiver has full responsibility for ultimately validate the
checksums and update various SNMP counters.
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Eric Dumazet @ 2013-08-19 0:00 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: Corey Hickey, Linux Netdev List, netfilter-devel
In-Reply-To: <alpine.DEB.2.00.1308182314050.25515@blackhole.kfki.hu>
On Sun, 2013-08-18 at 23:23 +0200, Jozsef Kadlecsik wrote:
> It's a PMTU related problem, so I'd suggest to check first the next ones:
>
> Aren't the ICMP error messages (i.e. fragmentation-needed) filtered out?
> If not, does adding an explicit TCPMSS rule to the mangle table help?
Thats totally irrelevant. tcp conntrack should not care of ICMP messages
anyway.
> Isn't there SACK options involved? Maybe there's a "smart" sequence
> number "anonymizer" device in the path which forgets about the SEQ numbers
> in the SACK options and thus such packets are marked as INVALID.
>
As I understood the report, they were no SACK at all, but plain ACK
messages, and conntrack believes these ACK are outside the window
because it remembers the @end sequence of the probe, and the @maxwin of
receiver.
Lets say the probe is 2000 bytes, seq 1:2001
conntrack records end = 2001
Of course this packet is lost.
The retransmit sends a 1000 bytes packet, seq 1:1001
conntrack pass the packet.
Receiver acks it using ack 1001
conntrack drops this ack because of some confusion about the prior 2001
end, and the window (might be as small as 1000)
Code like this seems very suspect to me :
before(sack, receiver->td_end + 1)
It basically says that conntrack doesn't deal with reorders on the
network.
> So tcpdumps captured at both sides could really help to tell what goes wrong.
We probably can reproduce this bug using packetdrill.
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Eric Dumazet @ 2013-08-19 0:03 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: Corey Hickey, Linux Netdev List, netfilter-devel
In-Reply-To: <1376870425.4226.25.camel@edumazet-glaptop>
On Sun, 2013-08-18 at 17:00 -0700, Eric Dumazet wrote:
> Code like this seems very suspect to me :
>
> before(sack, receiver->td_end + 1)
>
My suggestion would be to try :
diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
index 2f80107..1862902 100644
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -656,12 +656,12 @@ static bool tcp_in_window(const struct nf_conn *ct,
pr_debug("tcp_in_window: I=%i II=%i III=%i IV=%i\n",
before(seq, sender->td_maxend + 1),
(in_recv_win ? 1 : 0),
- before(sack, receiver->td_end + 1),
+ before(sack, receiver->td_end + MAXACKWINDOW(sender) + 1),
after(sack, receiver->td_end - MAXACKWINDOW(sender) - 1));
if (before(seq, sender->td_maxend + 1) &&
in_recv_win &&
- before(sack, receiver->td_end + 1) &&
+ before(sack, receiver->td_end + MAXACKWINDOW(sender) + 1) &&
after(sack, receiver->td_end - MAXACKWINDOW(sender) - 1)) {
/*
* Take into account window scaling (RFC 1323).
^ permalink raw reply related
* Re: [PATCH net] skge: dma_sync the whole receive buffer
From: poma @ 2013-08-19 0:49 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20130815084117.2f48fc58@nehalam.linuxnetplumber.net>
On 15.08.2013 17:41, Stephen Hemminger wrote:
> On Wed, 14 Aug 2013 20:29:06 +0200
> poma <pomidorabelisima@gmail.com> wrote:
>
>> On 14.08.2013 18:20, Stephen Hemminger wrote:
>>> On Wed, 14 Aug 2013 12:20:03 +0200
>>> poma <pomidorabelisima@gmail.com> wrote:
>>>
>>>> On 14.08.2013 03:00, Stephen Hemminger wrote:
>>>>> On Tue, 13 Aug 2013 15:09:55 -0700 (PDT)
>>>>> David Miller <davem@davemloft.net> wrote:
>>>>>
>>>>>> From: Stephen Hemminger <stephen@networkplumber.org>
>>>>>> Date: Sat, 10 Aug 2013 15:02:07 -0700
>>>>>>
>>>>>>> The DMA sync should sync the whole receive buffer, not just
>>>>>>> part of it. Fixes log messages dma_sync_check.
>>>>>>>
>>>>>>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>>>>>>
>>>>>> Applied, but I really suspect that your "check DMA mapping errors"
>>>>>> patch has added a serious regression. A regression much worse than
>>>>>> the bug you were trying to fix with that change.
>>>>>
>>>>> Argh. The problem is deeper than that. Device got broken somewhere between
>>>>> 3.2 and 3.4. My old Dlink card works on 3.2 but gets DMA errors on 3.4.
>>>>> The config's are different though so checking that as well.
>>>>>
>>>>
>>>> Can I help you with debugging?
>>>> DGE-530T is rather solid device.
>>>
>>> Don't think it is a hardware problem.
>>> The failure is when the board access the Receive ring PCI memory area.
>>> This region is allocated with pci_alloc_consistent and therefore should
>>> be available. Two possible issues are driver math issues, or hardware
>>> problems with where the region is located. Some of these cards don't
>>> really have full 64 bit PCI support.
>>>
>>> My board is:
>>> 05:01.0 Ethernet controller: D-Link System Inc Gigabit Ethernet Adapter (rev 11)
>>> Subsystem: D-Link System Inc DGE-530T Gigabit Ethernet Adapter
>>> Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 18
>>> Memory at f7d20000 (32-bit, non-prefetchable) [size=16K]
>>> I/O ports at c000 [size=256]
>>> Expansion ROM at f7d00000 [disabled] [size=128K]
>>> Capabilities: [48] Power Management version 2
>>> Capabilities: [50] Vital Product Data
>>> Kernel driver in use: skge
>>>
>>>
>>> What is your config?
>>>
>>
>> 01:09.0 Ethernet controller: D-Link System Inc Gigabit Ethernet Adapter
>> (rev 11)
>> Subsystem: D-Link System Inc DGE-530T Gigabit Ethernet Adapter
>> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 19
>> Memory at fbffc000 (32-bit, non-prefetchable) [size=16K]
>> I/O ports at b400 [size=256]
>> [virtual] Expansion ROM at ec000000 [disabled] [size=128K]
>> Capabilities: [48] Power Management version 2
>> Capabilities: [50] Vital Product Data
>> Kernel driver in use: skge
>>
>>
>> poma
>>
>
> In the course of debugging this, I moved the card to another slot
> and all the problems went away. I suspect either card insertion or more likely
> the crap consumer motherboards don't have full PCI support on some slots.
>
> There doesn't seem to be anyway to address this in software.
>
DGE-530T is further tested in the 3 available slots:
01:06.0 Ethernet controller: D-Link System Inc Gigabit Ethernet Adapter
(rev 11)
01:07.0 Ethernet controller: D-Link System Inc Gigabit Ethernet Adapter
(rev 11)
01:08.0 Ethernet controller: D-Link System Inc Gigabit Ethernet Adapter
(rev 11)
And the result is the same as in the slot:
01:09.0 Ethernet controller: D-Link System Inc Gigabit Ethernet Adapter
(rev 11)
warnings, oopses and kernel crashes.
However DGE-528T(RTL8110s) on the same bus runs without errors:
01:09.0 Ethernet controller: D-Link System Inc DGE-528T Gigabit Ethernet
Adapter (rev 10)
Subsystem: D-Link System Inc DGE-528T Gigabit Ethernet Adapter
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 19
I/O ports at cc00 [size=256]
Memory at fbfff000 (32-bit, non-prefetchable) [size=256]
[virtual] Expansion ROM at fbe00000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Kernel driver in use: r8169
Besides comparing the behavior of these two cards, e.g. NFS upload, I
noticed an obvious difference in the data flow.
Via DGE-528T transmission is steady, while via DGE-530T the traffic is
at times interrupted and unstable.
So it seems that the "WARNING: at lib/dma-debug.c:937 check_unmap…"
isn't just a fun.
poma
^ permalink raw reply
* Re: [GLIBC Patch v2] inet: avoid redefinition of some structs in kernel
From: Cong Wang @ 2013-08-19 1:20 UTC (permalink / raw)
To: Carlos O'Donell
Cc: netdev, David S. Miller, Thomas Backlund, libc-alpha,
YOSHIFUJI Hideaki
In-Reply-To: <520E4995.5090101@redhat.com>
On Fri, 2013-08-16 at 11:47 -0400, Carlos O'Donell wrote:
> On 08/15/2013 05:28 AM, Cong Wang wrote:
> > 2013-08-13 Carlos O'Donell <carlos@redhat.com>
> > Cong Wang <amwang@redhat.com>
> >
> > * sysdeps/unix/sysv/linux/bits/in.h
> > [_UAPI_LINUX_IN6_H]: Define __USE_KERNEL_IPV6_DEFS.
> > * inet/netinet/in.h: Move in_addr definition and bits/in.h inclusion
> > before __USE_KERNEL_IPV6_DEFS uses.
> > * inet/netinet/in.h [!__USE_KERNEL_IPV6_DEFS]: Define IPPROTO_MH, and
> > IPPROTO_BEETPH.
> > [__USE_KERNEL_IPV6_DEFS]: Don't define any of IPPROTO_*, in6_addr,
> > sockaddr_in6, or ipv6_mreq.
>
> Cong,
>
> Given that this is a user visible change could you please file
> a glibc bugzilla bug in sourceware[1] so we can track the commit and so
> that future users can reopen the bug to discuss any defects?
Done, http://sourceware.org/bugzilla/show_bug.cgi?id=15850
>
> Then you need to add the BZ# to the ChangeLog, and whomever
> commits this for you will mark it fixed in the NEWS. We should
> also write up a NEWS blurb for this since it's the first explicit
> header coordination of it's kind and we should highlight that
> so developers take note and help us coordinate more headers.
>
Should I resend this patch with BZ# included?
Thanks!
^ permalink raw reply
* [PATCH v2] vhost: Include linux/uio.h instead of linux/socket.h
From: Asias He @ 2013-08-19 1:23 UTC (permalink / raw)
To: netdev; +Cc: kvm, Michael S. Tsirkin, virtualization, David Miller
In-Reply-To: <20130816.222946.421410239742571372.davem@davemloft.net>
memcpy_fromiovec is moved from net/core/iovec.c to lib/iovec.c.
linux/uio.h provides the declaration for memcpy_fromiovec.
Include linux/uio.h instead of inux/socket.h for it.
Signed-off-by: Asias He <asias@redhat.com>
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index e58cf00..448efe0 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -13,7 +13,7 @@
#include <linux/eventfd.h>
#include <linux/vhost.h>
-#include <linux/socket.h> /* memcpy_fromiovec */
+#include <linux/uio.h>
#include <linux/mm.h>
#include <linux/mmu_context.h>
#include <linux/miscdevice.h>
--
1.8.3.1
^ permalink raw reply related
* Re: Where are OVS VXLAN patches?
From: Cong Wang @ 2013-08-19 1:23 UTC (permalink / raw)
To: Jesse Gross; +Cc: Stephen Hemminger, netdev, David S. Miller, Pravin B Shelar
In-Reply-To: <CAEP_g=9+aLyfY_3TaLkdHeKJGRUHtNFcjk=0w-DEUQ7Q_iHjGw@mail.gmail.com>
On Fri, 2013-08-16 at 08:58 -0700, Jesse Gross wrote:
> David, if you just want to take the whole series at this point, there
> shouldn't be any conflicts on my end and that way we can finally get
> this in.
>
_I think_ Pravin needs to repost them since they are not in patchwork
any more.
^ permalink raw reply
* [PATCH net-next] ipv4: raise IP_MAX_MTU to theoretical limit
From: Eric Dumazet @ 2013-08-19 2:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Willem de Bruijn, Alexey Kuznetsov
From: Eric Dumazet <edumazet@google.com>
As discussed last year [1], there is no compelling reason
to limit IPv4 MTU to 0xFFF0, while real limit is 0xFFFF
[1] : http://marc.info/?l=linux-netdev&m=135607247609434&w=2
Willem raised this issue again because some of our internal
regression tests broke after lo mtu being set to 65536.
IP_MTU reports 0xFFF0, and the test attempts to send a RAW datagram of
mtu + 1 bytes, expecting the send() to fail, but it does not.
Alexey raised interesting points about TCP MSS, that should be addressed
in follow-up patches in TCP stack if needed, as someone could also set
an odd mtu anyway.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: Willem de Bruijn <willemb@google.com>
---
net/ipv4/route.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index e805481..727f436 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -112,7 +112,8 @@
#define RT_FL_TOS(oldflp4) \
((oldflp4)->flowi4_tos & (IPTOS_RT_MASK | RTO_ONLINK))
-#define IP_MAX_MTU 0xFFF0
+/* IPv4 datagram length is stored into 16bit field (tot_len) */
+#define IP_MAX_MTU 0xFFFF
#define RT_GC_TIMEOUT (300*HZ)
@@ -1227,10 +1228,7 @@ static unsigned int ipv4_mtu(const struct dst_entry *dst)
mtu = 576;
}
- if (mtu > IP_MAX_MTU)
- mtu = IP_MAX_MTU;
-
- return mtu;
+ return min_t(unsigned int, mtu, IP_MAX_MTU);
}
static struct fib_nh_exception *find_exception(struct fib_nh *nh, __be32 daddr)
^ permalink raw reply related
* Re: [PATCH ipsec 1/3] ipv6: wire up skb->encapsulation
From: Simon Horman @ 2013-08-19 0:56 UTC (permalink / raw)
To: netdev, steffen.klassert, yoshfuji, nicolas.dichtel
In-Reply-To: <20130818110038.GC7371@order.stressinduktion.org>
On Sun, Aug 18, 2013 at 01:00:38PM +0200, Hannes Frederic Sowa wrote:
> On Sun, Aug 18, 2013 at 02:24:16PM +1000, Simon Horman wrote:
> > On Sat, Aug 17, 2013 at 08:07:38PM +0200, Hannes Frederic Sowa wrote:
> > > Hi Simon!
> > >
> > > On Sat, Aug 17, 2013 at 07:51:16PM +0200, Hannes Frederic Sowa wrote:
> > > > When pushing a new header before current one call skb_reset_inner_headers
> > > > to record the position of the inner headers in the various ipv6 tunnel
> > > > protocols.
> > > >
> > > > We later need this to correctly identify the addresses needed to send
> > > > back an error in the xfrm layer.
> > > >
> > > > This change is safe, because skb->protocol is always checked before
> > > > dereferencing data from the inner protocol.
> > > >
> > > > Cc: Steffen Klassert <steffen.klassert@secunet.com>
> > > > Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> > > > Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> > > > Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > > > ---
> > > >
> > > > This patch is based on Steffen Klassert's ipsec tree.
> > > >
> > > > net/ipv6/ip6_gre.c | 5 +++++
> > > > net/ipv6/ip6_tunnel.c | 6 ++++++
> > > > net/ipv6/sit.c | 5 +++++
> > > > 3 files changed, 16 insertions(+)
> > > >
> > > > diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
> > > > index ecd6073..90747f1 100644
> > > > --- a/net/ipv6/ip6_gre.c
> > > > +++ b/net/ipv6/ip6_gre.c
> > > > @@ -724,6 +724,11 @@ static netdev_tx_t ip6gre_xmit2(struct sk_buff *skb,
> > > > ipv6_push_nfrag_opts(skb, &opt.ops, &proto, NULL);
> > > > }
> > > >
> > > > + if (likely(!skb->encapsulation)) {
> > > > + skb_reset_inner_headers(skb);
> > > > + skb->encapsulation = 1;
> > > > + }
> > > > +
> > >
> > > While doing these patches, I wondered how skb->inner_protocol will be
> > > used in future (you added it in 0d89d2035fe063461a5ddb609b2c12e7fb006e44
> > > ("MPLS: Add limited GSO support")). Current use by tunnels seems safe to
> > > me, but I wondered how you would extend its use?
> >
> > Hi,
> >
> > I must confess that I'm not entirely sure that I understand the question.
>
> Sorry to be not clear enough. I try to present my envisioned use case for
> inner_protocol:
>
> I do think there may be some other corner cases when reporting back
> errors to a local socket when multiple tunnels+ipsecs are stacked into
> each other. The first encapsulation sets skb->inner_network_header, so
> that we can later extract the needed information for the error generation
> via inner_ip{v6,}_hdr. It would be handy here to use inner_protocol to
> mark the type of inner_network_header in advance (all this is because,
> even if we still have a reference to the local socket and know its af,
> it could also have emitted an IPv4 frame, so we have to jump to the ipv4
> error handling path).
That sounds reasonable to me and I don't think it would interfere
with the current usage or vice versa.
^ permalink raw reply
* Re: [RFC][PATCH 2/2] bgmac: pass received packet to the netif instead of copying it
From: Felix Fietkau @ 2013-08-19 4:36 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Network Development, Jonas Gorski, Hauke Mehrtens,
OpenWrt Development List
In-Reply-To: <CACna6rwi1+2ghyyKonaw=6xVDwipb3=1zUzOJ7dVoNoVyRx9fw@mail.gmail.com>
On 2013-08-15 10:21 PM, Rafał Miłecki wrote:
> 2013/8/15 Felix Fietkau <nbd@openwrt.org>:
>> On 2013-08-15 1:36 PM, Rafał Miłecki wrote:
>>> 2013/8/11 Rafał Miłecki <zajec5@gmail.com>:
>>>> It makes more sense to allocate new (empty) skb and pass it to the
>>>> hardware. That way we avoid copying whole packet into new skb which
>>>> should result in better performance.
>>>
>>> I did some testing of this patch using "perf" tool and iperf -s
>>> running on the OpenWrt machine (with bgmac supported hardware).
>>>
>>> So you can see that __copy_user_common usage has really decreased with
>>> this patch!
>>>
>>> Unfortunately it didn't result in better performance... no idea why :(
>> Running iperf on the router is not useful as an indicator of routing
>> performance. Please focus on tests where you only push traffic through
>> the router, not directly to it.
>
> OK, so I started "iperf -s" on notebook plugged into WAN port, and
> then played with "iperf -c" on notebook connected to LAN#2.
>
> With some old 3.6.11 based OpenWrt build I got:
> [ 4] 0.0-60.0 sec 690 MBytes 96.4 Mbits/sec
>
> With very recent 3.10.4 based OpenWrt build:
> [ 4] 0.0-60.0 sec 667 MBytes 93.2 Mbits/sec
>
> After applying my patch on top of that 3.10.4:
> [ 5] 0.0-60.0 sec 759 MBytes 106 Mbits/sec
>
> And some dumps from "perf top":
>
> 3.10.4
> 6.75% [kernel] [k] __copy_user_common
> 6.73% [ip_tables] [k] ipt_do_table
> 4.33% [kernel] [k] arch_cpu_idle
> 3.96% [kernel] [k] arch_local_irq_restore
> 3.42% [bgmac] [k] 0x000007e0
> 3.35% [nf_conntrack] [k] nf_conntrack_proto_fini
> 2.72% [nf_conntrack] [k] nf_conntrack_in
> 2.50% [kernel] [k] __netif_receive_skb_core
> 2.42% [kernel] [k] r4k_dma_cache_inv
> 2.38% [kernel] [k] fib_table_lookup
> 2.20% [kernel] [k] dev_queue_xmit
> 2.11% [xt_conntrack] [k] 0x00000360
> 2.10% [kernel] [k] ip_route_input_noref
> 2.06% [nf_conntrack_ipv4] [k] need_ipv4_conntrack
>
> 3.10.4 + 0002-bgmac-pass-received-packet-to-the-netif-instead-of-c.patch
> 6.09% [ip_tables] [k] ipt_do_table
> 4.71% [kernel] [k] arch_cpu_idle
> 4.48% [bgmac] [k] 0x00000d7c
> 3.50% [nf_conntrack] [k] nf_conntrack_in
> 3.22% [kernel] [k] arch_local_irq_restore
> 3.16% [nf_conntrack] [k] nf_conntrack_proto_fini
> 2.88% [kernel] [k] __netif_receive_skb_core
> 2.78% [xt_conntrack] [k] 0x0000011c
> 2.69% [kernel] [k] r4k_dma_cache_inv
> 2.67% [iptable_nat] [k] 0x000002a0
> 2.36% [kernel] [k] ip_route_input_noref
> 2.27% [kernel] [k] ip_rcv
> 2.25% [nf_conntrack_ipv4] [k] need_ipv4_conntrack
> 2.23% [kernel] [k] nf_iterate
>
> I've compiled bgmac into the kernel and it seems that the magic 0xd7c
> was bgmac_poll.
>
> I'm afraid this "perf top" output doesn't really tell us where to look
> for optimizations :| I'll still try Felix ideas tomorrow, but I'm not
> sure if they help, since there isn't __copy_user_common anymore in the
> "perf top" output...
What's the CPU load while passing traffic without running perf?
Have you tested bridging performance?
- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
^ permalink raw reply
* 3.11-rc6 genetlink locking fix offends lockdep
From: Hugh Dickins @ 2013-08-19 5:04 UTC (permalink / raw)
To: Johannes Berg
Cc: Linus Torvalds, Greg KH, David S. Miller, Andrei Otcheretianski,
linux-kernel, netdev, stable
3.11-rc6's commit 58ad436fcf49 ("genetlink: fix family dump race")
gives me the lockdep trace below at startup.
I think it needs to be reverted until you can refine it. And it has
already gone into today's stable review series, as 04/12 for 3.0.92,
26/34 for 3.4.59, 18/45 for 3.10.8: I raise an objection to those.
Hugh
[ 4.004286] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
[ 4.105671] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
[ 4.106123] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 4.110096]
[ 4.110113] ======================================================
[ 4.110146] [ INFO: possible circular locking dependency detected ]
[ 4.110180] 3.11.0-rc6 #1 Not tainted
[ 4.110201] -------------------------------------------------------
[ 4.110234] NetworkManager/358 is trying to acquire lock:
[ 4.110262] (genl_mutex){+.+.+.}, at: [<ffffffff8148204d>] genl_lock+0x12/0x14
[ 4.110315]
[ 4.110315] but task is already holding lock:
[ 4.110346] (nlk->cb_mutex){+.+.+.}, at: [<ffffffff8147f148>] netlink_dump+0x1c/0x1d7
[ 4.110400]
[ 4.110400] which lock already depends on the new lock.
[ 4.110400]
[ 4.110442]
[ 4.110442] the existing dependency chain (in reverse order) is:
[ 4.110482]
[ 4.110482] -> #1 (nlk->cb_mutex){+.+.+.}:
[ 4.110517] [<ffffffff810b34d2>] __lock_acquire+0x865/0x956
[ 4.110555] [<ffffffff810b39fc>] lock_acquire+0x57/0x6d
[ 4.110589] [<ffffffff81583e42>] mutex_lock_nested+0x5e/0x345
[ 4.110627] [<ffffffff81480122>] __netlink_dump_start+0xae/0x14e
[ 4.110665] [<ffffffff81482143>] genl_rcv_msg+0xf4/0x252
[ 4.110699] [<ffffffff81481742>] netlink_rcv_skb+0x3e/0x8c
[ 4.110734] [<ffffffff8148199b>] genl_rcv+0x24/0x34
[ 4.110766] [<ffffffff814811ca>] netlink_unicast+0xed/0x17a
[ 4.110801] [<ffffffff814815d4>] netlink_sendmsg+0x2fb/0x345
[ 4.110838] [<ffffffff814503f7>] sock_sendmsg+0x79/0x8e
[ 4.110871] [<ffffffff81450707>] ___sys_sendmsg+0x231/0x2be
[ 4.110907] [<ffffffff81453228>] __sys_sendmsg+0x3d/0x5e
[ 4.110942] [<ffffffff81453256>] SyS_sendmsg+0xd/0x19
[ 4.110975] [<ffffffff81587c12>] system_call_fastpath+0x16/0x1b
[ 4.111012]
[ 4.111012] -> #0 (genl_mutex){+.+.+.}:
[ 4.111047] [<ffffffff810b1fb0>] validate_chain.isra.21+0x836/0xe8e
[ 4.111086] [<ffffffff810b34d2>] __lock_acquire+0x865/0x956
[ 4.111122] [<ffffffff810b39fc>] lock_acquire+0x57/0x6d
[ 4.111157] [<ffffffff81583e42>] mutex_lock_nested+0x5e/0x345
[ 4.111193] [<ffffffff8148204d>] genl_lock+0x12/0x14
[ 4.111226] [<ffffffff814822d2>] ctrl_dumpfamily+0x31/0xfa
[ 4.111260] [<ffffffff8147f1b4>] netlink_dump+0x88/0x1d7
[ 4.111295] [<ffffffff8147f4b4>] netlink_recvmsg+0x1b1/0x2d1
[ 4.111331] [<ffffffff81450328>] sock_recvmsg+0x83/0x98
[ 4.111365] [<ffffffff814500c6>] ___sys_recvmsg+0x15d/0x207
[ 4.111400] [<ffffffff814533f7>] __sys_recvmsg+0x3d/0x5e
[ 4.111434] [<ffffffff81453425>] SyS_recvmsg+0xd/0x19
[ 4.111467] [<ffffffff81587c12>] system_call_fastpath+0x16/0x1b
[ 4.111504]
[ 4.111504] other info that might help us debug this:
[ 4.111504]
[ 4.111545] Possible unsafe locking scenario:
[ 4.111545]
[ 4.111577] CPU0 CPU1
[ 4.111601] ---- ----
[ 4.111625] lock(nlk->cb_mutex);
[ 4.112865] lock(genl_mutex);
[ 4.114216] lock(nlk->cb_mutex);
[ 4.115315] lock(genl_mutex);
[ 4.116500]
[ 4.116500] *** DEADLOCK ***
[ 4.116500]
[ 4.119670] 1 lock held by NetworkManager/358:
[ 4.120906] #0: (nlk->cb_mutex){+.+.+.}, at: [<ffffffff8147f148>] netlink_dump+0x1c/0x1d7
[ 4.122196]
[ 4.122196] stack backtrace:
[ 4.124533] CPU: 0 PID: 358 Comm: NetworkManager Not tainted 3.11.0-rc6 #1
[ 4.125779] Hardware name: LENOVO 4174EH1/4174EH1, BIOS 8CET51WW (1.31 ) 11/29/2011
[ 4.126979] ffffffff81d0a0f0 ffff88022b91d8c8 ffffffff8157cf80 0000000000000006
[ 4.128274] ffffffff81cc8750 ffff88022b91d918 ffffffff8157a898 ffff88022d798080
[ 4.129472] ffff88022d798080 ffff88022d798080 ffff88022d798750 ffff88022d798080
[ 4.130645] Call Trace:
[ 4.131801] [<ffffffff8157cf80>] dump_stack+0x4f/0x84
[ 4.132817] [<ffffffff8157a898>] print_circular_bug+0x2ad/0x2be
[ 4.133839] [<ffffffff810b1fb0>] validate_chain.isra.21+0x836/0xe8e
[ 4.134821] [<ffffffff8145471a>] ? sock_def_write_space+0x1b5/0x1b5
[ 4.135800] [<ffffffff810b34d2>] __lock_acquire+0x865/0x956
[ 4.136842] [<ffffffff810b40bb>] ? mark_held_locks+0xce/0xfa
[ 4.137828] [<ffffffff8148204d>] ? genl_lock+0x12/0x14
[ 4.138876] [<ffffffff810b39fc>] lock_acquire+0x57/0x6d
[ 4.139856] [<ffffffff8148204d>] ? genl_lock+0x12/0x14
[ 4.141027] [<ffffffff81583e42>] mutex_lock_nested+0x5e/0x345
[ 4.142194] [<ffffffff8148204d>] ? genl_lock+0x12/0x14
[ 4.143219] [<ffffffff8111c594>] ? __kmalloc_node_track_caller+0x26/0x2d
[ 4.144340] [<ffffffff8148204d>] genl_lock+0x12/0x14
[ 4.145387] [<ffffffff814822d2>] ctrl_dumpfamily+0x31/0xfa
[ 4.146387] [<ffffffff8145ac41>] ? __alloc_skb+0x97/0x1a0
[ 4.147454] [<ffffffff8147f1b4>] netlink_dump+0x88/0x1d7
[ 4.148448] [<ffffffff8147f4b4>] netlink_recvmsg+0x1b1/0x2d1
[ 4.149475] [<ffffffff81450328>] sock_recvmsg+0x83/0x98
[ 4.150494] [<ffffffff810f86fa>] ? might_fault+0x52/0xa2
[ 4.151471] [<ffffffff814500c6>] ___sys_recvmsg+0x15d/0x207
[ 4.152516] [<ffffffff810b34d2>] ? __lock_acquire+0x865/0x956
[ 4.153501] [<ffffffff81148b2b>] ? fget_light+0x35c/0x377
[ 4.154550] [<ffffffff81148933>] ? fget_light+0x164/0x377
[ 4.155521] [<ffffffff814533f7>] __sys_recvmsg+0x3d/0x5e
[ 4.156568] [<ffffffff8145471a>] ? sock_def_write_space+0x1b5/0x1b5
[ 4.157552] [<ffffffff81453425>] SyS_recvmsg+0xd/0x19
[ 4.158607] [<ffffffff81587c12>] system_call_fastpath+0x16/0x1b
[ 4.160507] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[ 4.160709] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
^ permalink raw reply
* [PATCH] ip: Add label option to ip monitor
From: Martin Schwenke @ 2013-08-19 5:43 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
Prefix labelling is currently only activated when monitoring "all"
objects. However, the output can still be confusing when monitoring
more than 1 object, so add an option to always print prefix labels.
Signed-off-by: Martin Schwenke <martin@meltin.net>
---
Really a reply to http://www.spinics.net/lists/netdev/msg246739.html
doc/ip-cref.tex | 16 +++++++++-------
ip/ipmonitor.c | 4 +++-
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/doc/ip-cref.tex b/doc/ip-cref.tex
index d8fed66..f062b3a 100644
--- a/doc/ip-cref.tex
+++ b/doc/ip-cref.tex
@@ -2542,13 +2542,15 @@ Namely,
the \verb|monitor| command is the first in the command line and then
the object list follows:
\begin{verbatim}
- ip monitor [ file FILE ] [ all | OBJECT-LIST ]
-\end{verbatim}
-\verb|OBJECT-LIST| is the list of object types that we want to monitor.
-It may contain \verb|link|, \verb|address| and \verb|route|.
-If no \verb|file| argument is given, \verb|ip| opens RTNETLINK,
-listens on it and dumps state changes in the format described
-in previous sections.
+ ip monitor [ file FILE ] [ all | OBJECT-LIST ] [ label ]
+\end{verbatim}
+\verb|OBJECT-LIST| is the list of object types that we want to
+monitor. It may contain \verb|link|, \verb|address| and \verb|route|.
+Specifying \verb|label| indicates that output lines should be labelled
+with the type of object being printed --- this happens by default if
+\verb|all| is specified. If no \verb|file| argument is given,
+\verb|ip| opens RTNETLINK, listens on it and dumps state changes in
+the format described in previous sections.
If a file name is given, it does not listen on RTNETLINK,
but opens the file containing RTNETLINK messages saved in binary format
diff --git a/ip/ipmonitor.c b/ip/ipmonitor.c
index 86c473e..4895390 100644
--- a/ip/ipmonitor.c
+++ b/ip/ipmonitor.c
@@ -29,7 +29,7 @@ int prefix_banner;
static void usage(void)
{
- fprintf(stderr, "Usage: ip monitor [ all | LISTofOBJECTS ] [ FILE ]\n");
+ fprintf(stderr, "Usage: ip monitor [ all | LISTofOBJECTS ] [ FILE ] [ label ]\n");
fprintf(stderr, "LISTofOBJECTS := link | address | route | mroute | prefix |\n");
fprintf(stderr, " neigh | netconf\n");
fprintf(stderr, "FILE := file FILENAME\n");
@@ -157,6 +157,8 @@ int do_ipmonitor(int argc, char **argv)
if (matches(*argv, "file") == 0) {
NEXT_ARG();
file = *argv;
+ } else if (matches(*argv, "label") == 0) {
+ prefix_banner = 1;
} else if (matches(*argv, "link") == 0) {
llink=1;
groups = 0;
--
1.7.10.4
^ permalink raw reply related
* [PATCH net 0/6] bnx2x: Bug fixes patch series
From: Yuval Mintz @ 2013-08-19 6:11 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, eilong
Hi Dave,
This patch series contains bug fixes, mostly for either DCBX
or VF configuration.
Please consider applying these patches to `net'.
Thanks,
Yuval Mintz
^ permalink raw reply
* [PATCH net 3/6] bnx2x: Consider DCBX remote error
From: Yuval Mintz @ 2013-08-19 6:11 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, eilong, Dmitry Kravkov, Yuval Mintz
In-Reply-To: <1376892721-10410-1-git-send-email-yuvalmin@broadcom.com>
From: Dmitry Kravkov <dmitry@broadcom.com>
When publishing information via getfeatcfg(), bnx2x driver didn't consider
remote errors (e.g., switch that doesn't support DCBX) when setting the
error flags.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c
index d537d51..fcf2761 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c
@@ -2391,21 +2391,24 @@ static u8 bnx2x_dcbnl_get_featcfg(struct net_device *netdev, int featid,
case DCB_FEATCFG_ATTR_PG:
if (bp->dcbx_local_feat.ets.enabled)
*flags |= DCB_FEATCFG_ENABLE;
- if (bp->dcbx_error & DCBX_LOCAL_ETS_ERROR)
+ if (bp->dcbx_error & (DCBX_LOCAL_ETS_ERROR |
+ DCBX_REMOTE_MIB_ERROR))
*flags |= DCB_FEATCFG_ERROR;
break;
case DCB_FEATCFG_ATTR_PFC:
if (bp->dcbx_local_feat.pfc.enabled)
*flags |= DCB_FEATCFG_ENABLE;
if (bp->dcbx_error & (DCBX_LOCAL_PFC_ERROR |
- DCBX_LOCAL_PFC_MISMATCH))
+ DCBX_LOCAL_PFC_MISMATCH |
+ DCBX_REMOTE_MIB_ERROR))
*flags |= DCB_FEATCFG_ERROR;
break;
case DCB_FEATCFG_ATTR_APP:
if (bp->dcbx_local_feat.app.enabled)
*flags |= DCB_FEATCFG_ENABLE;
if (bp->dcbx_error & (DCBX_LOCAL_APP_ERROR |
- DCBX_LOCAL_APP_MISMATCH))
+ DCBX_LOCAL_APP_MISMATCH |
+ DCBX_REMOTE_MIB_ERROR))
*flags |= DCB_FEATCFG_ERROR;
break;
default:
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH net 1/6] bnx2x: dropless flow control not always functional
From: Yuval Mintz @ 2013-08-19 6:11 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, eilong, Dmitry Kravkov, Yuval Mintz
In-Reply-To: <1376892721-10410-1-git-send-email-yuvalmin@broadcom.com>
From: Dmitry Kravkov <dmitry@broadcom.com>
Since commit 3deb816 "bnx2x: Add a periodic task for link PHY events"
link state changes can be detected not only via the attention flow but also
from the periodic task.
If the link state will change in such a manner (i.e., via the periodic task),
dropless flow-control will not be configured.
This patch remedies the issue, adding the missing configuration to all required
flows.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 36 +++++++++++++++---------
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 955d6cf..c009f19 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -2261,6 +2261,23 @@ static void bnx2x_set_requested_fc(struct bnx2x *bp)
bp->link_params.req_fc_auto_adv = BNX2X_FLOW_CTRL_BOTH;
}
+static void bnx2x_init_dropless_fc(struct bnx2x *bp)
+{
+ u32 pause_enabled = 0;
+
+ if (!CHIP_IS_E1(bp) && bp->dropless_fc && bp->link_vars.link_up) {
+ if (bp->link_vars.flow_ctrl & BNX2X_FLOW_CTRL_TX)
+ pause_enabled = 1;
+
+ REG_WR(bp, BAR_USTRORM_INTMEM +
+ USTORM_ETH_PAUSE_ENABLED_OFFSET(BP_PORT(bp)),
+ pause_enabled);
+ }
+
+ DP(NETIF_MSG_IFUP | NETIF_MSG_LINK, "dropless_fc is %s\n",
+ pause_enabled ? "enabled" : "disabled");
+}
+
int bnx2x_initial_phy_init(struct bnx2x *bp, int load_mode)
{
int rc, cfx_idx = bnx2x_get_link_cfg_idx(bp);
@@ -2294,6 +2311,8 @@ int bnx2x_initial_phy_init(struct bnx2x *bp, int load_mode)
bnx2x_release_phy_lock(bp);
+ bnx2x_init_dropless_fc(bp);
+
bnx2x_calc_fc_adv(bp);
if (bp->link_vars.link_up) {
@@ -2315,6 +2334,8 @@ void bnx2x_link_set(struct bnx2x *bp)
bnx2x_phy_init(&bp->link_params, &bp->link_vars);
bnx2x_release_phy_lock(bp);
+ bnx2x_init_dropless_fc(bp);
+
bnx2x_calc_fc_adv(bp);
} else
BNX2X_ERR("Bootcode is missing - can not set link\n");
@@ -2556,20 +2577,9 @@ static void bnx2x_link_attn(struct bnx2x *bp)
bnx2x_link_update(&bp->link_params, &bp->link_vars);
- if (bp->link_vars.link_up) {
-
- /* dropless flow control */
- if (!CHIP_IS_E1(bp) && bp->dropless_fc) {
- int port = BP_PORT(bp);
- u32 pause_enabled = 0;
-
- if (bp->link_vars.flow_ctrl & BNX2X_FLOW_CTRL_TX)
- pause_enabled = 1;
+ bnx2x_init_dropless_fc(bp);
- REG_WR(bp, BAR_USTRORM_INTMEM +
- USTORM_ETH_PAUSE_ENABLED_OFFSET(port),
- pause_enabled);
- }
+ if (bp->link_vars.link_up) {
if (bp->link_vars.mac_type != MAC_TYPE_EMAC) {
struct host_port_stats *pstats;
--
1.8.1.227.g44fe835
^ 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