* Re: [iproute2 PATCH] iproute2: linklayer interface between kernel and tc/userspace
From: Stephen Hemminger @ 2013-09-03 15:33 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20130830120210.1510.80733.stgit@localhost>
On Fri, 30 Aug 2013 14:02:10 +0200
Jesper Dangaard Brouer <brouer@redhat.com> wrote:
> This iproute2 tc patch is connected to the kernel
> - commit 8a8e3d84b17 (net_sched: restore "linklayer atm" handling)
>
> The rate table calculated by tc, have gotten replaced in the kernel
> and is no-longer used for lookups.
>
> This happened in kernel release v3.8 caused by kernel
> - commit 56b765b79 ("htb: improved accuracy at high rates").
> This change unfortunately caused breakage of tc overhead and
> linklayer parameters.
>
> Kernel overhead handling got fixed in kernel v3.10 by
> - commit 01cb71d2d47 (net_sched: restore "overhead xxx" handling)
>
> Kernel linklayer handling got fixed in kernel v3.11 by
> - commit 8a8e3d84b17 (net_sched: restore "linklayer atm" handling)
>
> The linklayer fix introduced a struct change, that allow the linklayer
> attribute to be transferred between tc and kernel. This patch make use
> of this linklayer attribute.
>
> The linklayer setting is transfer to the kernel. And linklayer
> setting received from the kernel is printed with a prefixed
> "linklayer" when listing current configuration. The default
> TC_LINKLAYER_ETHERNET is only printed in detailed output mode.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Ok, Applied for 3.11
^ permalink raw reply
* [ANNOUNCE] iprotue2 v3.11.0
From: Stephen Hemminger @ 2013-09-03 15:32 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
Iproute2 tools for Workgroups (3.11) is not available.
It has the usual set of fixes and support for the new features
in 3.11. Thank for all the contributions.
I will merge in the next-3.11 branch. After that
if you have been sitting on changes to iproute2 that are in
net-next for 3.12 merge window, please submit them now.
Iproute2 package is available at:
http://kernel.org/pub/linux/utils/net/iproute2/iproute2-3.10.0.tar.gz
You can download the source from:
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git
---
Adam Borowski (1):
ip: fix build failure if time_t is not long int
Alexander Duyck (1):
iproute2: act_ipt fix xtables breakage on older versions.
Amerigo Wang (1):
iptunnel: check SIT_ISATAP flag only for SIT tunnel
Andreas Henriksson (1):
iproute2: fix build failure on sparc due to -Wformat and tv_usec
Andrey Vagin (5):
ip: set the close-on-exec flag for descriptors
ss: handle socket diag request in a separate function
ss: create a function to print info about netlink sockets
ss: show destination address for netlink sockets
ss: Get netlink sockets info via sock-diag (v2)
Atzm Watanabe (1):
vxlan: Allow setting destination to unicast address.
Cong Wang (1):
add quickack option to ip route
Daniel Borkmann (1):
ip: ipv6: add tokenized interface identifier support
David L Stevens (1):
iproute2: support NTF_ROUTER flag in VXLAN fdb entries
David Stevens (1):
iproute2: generalize VXLAN forwarding tables
Eric Dumazet (4):
ss: add fastopen support
htb: report overhead attribute
get_rate: detect 32bit overflows
ss: add more TCP_INFO components
Jesper Dangaard Brouer (1):
linklayer interface between kernel and tc/userspace
John Fastabend (1):
iproute2: bridge: fix 'bridge link' setlink/getlink parsing
JunweiZhang (1):
ipbatch: fix use of 'ip netns exec'
Kamil Rytarowski (1):
iproute2 patch against GCC 4.8.0
Lutz Jaenicke (1):
macvlan: fix typo in macvlan_print_opt()
Martin Schwenke (1):
ip: Add label option to ip monitor
Nicolas Dichtel (8):
ip: add missing help about mode argument
ip/xfrm: all to set flag XFRM_SA_XFLAG_DONT_ENCAP_DSCP
ipnetconf: by default dump all entries
ss: allow to retrieve AF_PACKET info via netlink
man: describe --bpf option of ss
ipadress: fix display of IPv6 peer address
ip: allow to specify mode for sit tunnels
ipnetns: fix ip batch mode when using 'netns exec'
Patric McHardy (1):
ip: iplink_vlan: add 802.1ad support
Pavel Emelyanov (1):
ss: Show inet and unix sockets' shutdown state
Rami Rosen (1):
ss: replace bfp with bpf in usage().
Richard Godbee (3):
iproute2: iproute.c: fix usage() spacing problems
iproute2: spelling: noptmudisc -> nopmtudisc
iproute2: ip-route.8.in: minor fixes
Rony Efraim (1):
Add VF link state control
Sriram Narasimhan (1):
iptuntap: allow creation of multi-queue tun/tap device
Stefan Tomanek (1):
ip link: fix display of interface groups
Stephen Hemminger (21):
Update headers to 3.10
Add vxlan destination port option
vxlan: nag user to set port value
add BPF header files
vxlan: remove dstport option
man: get rid of useless reference to GNU style options
htb: fix indentation
update to 3.10-net-next headers
netns: follow return value conventions of the rest of the code
ip: add batch mode to man page
Make tc and ip batch mode consistent
v3.10.0
Update to 3.11-rc1 kernel headers
Remove -Werror
cleanup help message
Fix spelling errors
More minor spelling fixes
tc: allow qdisc without options
add ability to filter neighbour discovery by protocol
Update kernel headers to 3.11
v3.11.0
Thomas Egerer (1):
ip/xfrm: Fix potential SIGSEGV when printing extra flags
Thomas Richter (3):
iproute2 vxlan documentation update for bridge command
iproute2 vxlan documentation update for ip command
iproute vxlan add support for fdb replace command
esr@thyrsus.com (4):
First set of manpage markup fixes
tc-stab.8: Fix synopsis errors, an invalid escape, and incorrect English usge.
In tc-ematch.8, remove no-op .ti requests to prevent translation warnings
ip-rule.8: Fix presentational use of .SS.
^ permalink raw reply
* Re: VLAN HW accel, performance advantage?
From: Eric Dumazet @ 2013-09-03 15:29 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Joakim Tjernlund, netdev
In-Reply-To: <1378219696.1545.9.camel@bwh-desktop.uk.level5networks.com>
On Tue, 2013-09-03 at 15:48 +0100, Ben Hutchings wrote:
> GRO should be beneficial for bridges if you have bursty TCP streams. It
> is especially beneficial if you also have TSO on the TX side.
>
> Really you're going to have to try it and run benchmarks with your own
> hardware.
Note that ucc_geth does not have GRO support (it calls
netif_receive_skb())
It doesnt have RX checksuming either, so having to validate
tcp checksums (before aggregating them in GRO stack) would hurt if
packets only have to be forwarded.
^ permalink raw reply
* RE: [PATCH] net: fec: fix the error to get the previous BD entry
From: Li Frank-B20596 @ 2013-09-03 15:20 UTC (permalink / raw)
To: Fabio Estevam
Cc: David Miller, Duan Fugang-B38611, netdev@vger.kernel.org,
bhutchings@solarflare.com, stephen@networkplumber.org
In-Reply-To: <CAOMZO5AHQr87ka2PrmMCQ0Dr46T=gB5_j1fz9BxhcjyWw9qSnw@mail.gmail.com>
> -----Original Message-----
> From: Fabio Estevam [mailto:festevam@gmail.com]
> Sent: Tuesday, September 03, 2013 10:15 AM
> To: Li Frank-B20596
> Cc: David Miller; Duan Fugang-B38611; netdev@vger.kernel.org;
> bhutchings@solarflare.com; stephen@networkplumber.org
> Subject: Re: [PATCH] net: fec: fix the error to get the previous BD entry
>
> On Tue, Sep 3, 2013 at 12:10 PM, Li Frank-B20596 <B20596@freescale.com>
> wrote:
> >
> >> > Acked
> >>
> >> This is not the correct way to ACK a patch, the correct format is:
> >>
> >> Acked-by: David S. Miller <davem@davemloft.net>
> >
> >
> > Thanks
> >
> > Acked-by: Frank Li <frank.li@freescale.net>
>
> I thought your email was freescale.com ;-)
Yes, I am wrong.
Sorry.
Acked-by: Frank Li <frank.li@freescale.com>
^ permalink raw reply
* Re: [PATCH] net: fec: fix the error to get the previous BD entry
From: Fabio Estevam @ 2013-09-03 15:14 UTC (permalink / raw)
To: Li Frank-B20596
Cc: David Miller, Duan Fugang-B38611, netdev@vger.kernel.org,
bhutchings@solarflare.com, stephen@networkplumber.org
In-Reply-To: <1F990F8245A4214A8CC4BFFBD9F790F908B46E06@039-SN1MPN1-001.039d.mgd.msft.net>
On Tue, Sep 3, 2013 at 12:10 PM, Li Frank-B20596 <B20596@freescale.com> wrote:
>
>> > Acked
>>
>> This is not the correct way to ACK a patch, the correct format is:
>>
>> Acked-by: David S. Miller <davem@davemloft.net>
>
>
> Thanks
>
> Acked-by: Frank Li <frank.li@freescale.net>
I thought your email was freescale.com ;-)
^ permalink raw reply
* RE: [PATCH] net: fec: fix the error to get the previous BD entry
From: Li Frank-B20596 @ 2013-09-03 15:10 UTC (permalink / raw)
To: David Miller
Cc: Duan Fugang-B38611, netdev@vger.kernel.org,
bhutchings@solarflare.com, stephen@networkplumber.org
In-Reply-To: <20130902.203506.1108904049878490946.davem@davemloft.net>
> > Acked
>
> This is not the correct way to ACK a patch, the correct format is:
>
> Acked-by: David S. Miller <davem@davemloft.net>
Thanks
Acked-by: Frank Li <frank.li@freescale.net>
^ permalink raw reply
* Re: VLAN HW accel, performance advantage?
From: Ben Hutchings @ 2013-09-03 14:48 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OF0F246C2A.B5DC5CA4-ONC1257BDB.004CA4E6-C1257BDB.004DB31E@transmode.se>
On Tue, 2013-09-03 at 16:08 +0200, Joakim Tjernlund wrote:
> Ben Hutchings <bhutchings@solarflare.com> wrote on 2013/09/03 15:50:16:
> >
> > On Tue, 2013-09-03 at 11:05 +0200, Joakim Tjernlund wrote:
> > > I am considering impl. VLAN HW acceleration in Freescales ucc_geth
> driver
> > > to improve
> > > performance, primarily for bridged interfaces.
> > > I am hoping the community has some insights as to what performance
> gains
> > > one
> > > could expect?
> >
> > At the moment you need to do VLAN RX offload (or fake it in software) to
> > take advantage of GRO for VLAN-encapsulated packets. Other than that, I
> > don't think it makes a lot of difference in most situations.
> >
> > Ben.
>
> Thanks Ben
>
> I figured one would avoid some memmoves if the tag was extracted and as we
> got
> a fairly slow CPU (some 300 MHZ MPC 8321) one should gain some performance
> but not so then.
Of course it will avoid some memmoves, I just don't think that makes
much of a difference any more. There used to be other more major
performance issues (like having to copy packets) but I believe they've
been fixed in the stack now.
> I am not familiar with GRO( and its friends) but I am guessing it won't
> help
> the bridge function or reduce stress from packet storms?
GRO should be beneficial for bridges if you have bursty TCP streams. It
is especially beneficial if you also have TSO on the TX side.
Really you're going to have to try it and run benchmarks with your own
hardware.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: use reciprocal_divide instead of reimplementing it
From: Daniel Borkmann @ 2013-09-03 14:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev, netfilter-devel
In-Reply-To: <1378216954.7360.25.camel@edumazet-glaptop>
On 09/03/2013 04:02 PM, Eric Dumazet wrote:
> On Tue, 2013-09-03 at 12:26 +0200, Daniel Borkmann wrote:
>> Replace these places with reciprocal_divide() inline function instead of
>> reimplementing it each time, thus it will become easier to read. We do not
>> need to explicitly include its header as it's pulled in from linux/net.h
>> anyway.
>
> Sure, (((u64) hash * qcount) >> 32) happens to be
> reciprocal_divide(hash, qcount) but the result depends on hash being
> well distributed in [0 .. ~0U] space.
>
> So 'reciprocal' and 'divide' do not accurately describe this exact
> operation.
>
> I suggest making the thing more descriptive.
>
> (And discussed on lkml btw)
Sure, we can do that. Then lets drop these two for now.
^ permalink raw reply
* Re: [guv v2 04/31] net: Replace __get_cpu_var uses
From: Christoph Lameter @ 2013-09-03 14:21 UTC (permalink / raw)
To: David Miller
Cc: dhowells, tj, akpm, netdev, linux-arch, srostedt, linux-kernel
In-Reply-To: <20130902.203355.117341085023152754.davem@davemloft.net>
On Mon, 2 Sep 2013, David Miller wrote:
> It really will cache pre-computed __thread pointer calculations across
> sched().
On x86 the compiler could use the segment prefix and then it may work.
^ permalink raw reply
* Re: [guv v2 04/31] net: Replace __get_cpu_var uses
From: Christoph Lameter @ 2013-09-03 14:20 UTC (permalink / raw)
To: David Howells
Cc: Tejun Heo, akpm, David S. Miller, netdev, linux-arch,
Steven Rostedt, linux-kernel
In-Reply-To: <7435.1378157706@warthog.procyon.org.uk>
On Mon, 2 Sep 2013, David Howells wrote:
> Would it be possible to use __thread annotations for per-CPU variables, I
> wonder?
We already have a __percpu annotation. Looked at __thread a couple of
years ago but found that support for the kernel segment register was not
available. If we had __thread then most of the operations could simply be
provided by the compiler.
^ permalink raw reply
* Re: [PATCH] net: sctp: Fix data chunk fragmentation for MTU values which are not multiple of 4
From: Vlad Yasevich @ 2013-09-03 14:16 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: linux-sctp, davem, Glavinic-Pecotic, Matija (EXT-Other - DE/Ulm),
netdev
In-Reply-To: <52249981.8040006@nsn.com>
On 09/02/2013 09:58 AM, Alexander Sverdlin wrote:
> From: Alexander Sverdlin <alexander.sverdlin@nsn.com>
>
> net: sctp: Fix data chunk fragmentation for MTU values which are not multiple of 4
>
> Initially the problem was observed with ipsec, but later it became clear that
> SCTP data chunk fragmentation algorithm has problems with MTU values which are
> not multiple of 4. Test program was used which just transmits 2000 bytes long
> packets to other host. tcpdump was used to observe re-fragmentation in IP layer
> after SCTP already fragmented data chunks.
>
> With MTU 1500:
> 12:54:34.082904 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto SCTP (132), length 1500)
> 10.151.38.153.39303 > 10.151.24.91.54321: sctp (1) [DATA] (B) [TSN: 2366088589] [SID: 0] [SSEQ 1] [PPID 0x0]
> 12:54:34.082933 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto SCTP (132), length 596)
> 10.151.38.153.39303 > 10.151.24.91.54321: sctp (1) [DATA] (E) [TSN: 2366088590] [SID: 0] [SSEQ 1] [PPID 0x0]
> 12:54:34.090576 IP (tos 0x2,ECT(0), ttl 63, id 0, offset 0, flags [DF], proto SCTP (132), length 48)
> 10.151.24.91.54321 > 10.151.38.153.39303: sctp (1) [SACK] [cum ack 2366088590] [a_rwnd 79920] [#gap acks 0] [#dup tsns 0]
>
> With MTU 1499:
> 13:02:49.955220 IP (tos 0x2,ECT(0), ttl 64, id 48215, offset 0, flags [+], proto SCTP (132), length 1492)
> 10.151.38.153.39084 > 10.151.24.91.54321: sctp[|sctp]
> 13:02:49.955249 IP (tos 0x2,ECT(0), ttl 64, id 48215, offset 1472, flags [none], proto SCTP (132), length 28)
> 10.151.38.153 > 10.151.24.91: ip-proto-132
> 13:02:49.955262 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto SCTP (132), length 600)
> 10.151.38.153.39084 > 10.151.24.91.54321: sctp (1) [DATA] (E) [TSN: 404355346] [SID: 0] [SSEQ 1] [PPID 0x0]
> 13:02:49.956770 IP (tos 0x2,ECT(0), ttl 63, id 0, offset 0, flags [DF], proto SCTP (132), length 48)
> 10.151.24.91.54321 > 10.151.38.153.39084: sctp (1) [SACK] [cum ack 404355346] [a_rwnd 79920] [#gap acks 0] [#dup tsns 0]
>
> Here problem in data portion limit calculation leads to re-fragmentation in IP,
> which is sub-optimal. The problem is max_data initial value, which doesn't take
> into account the fact, that data chunk must be padded to 4-bytes boundary.
> It's enough to correct max_data, because all later adjustments are correctly
> aligned to 4-bytes boundary.
>
> After the fix is applied, everything is fragmented correctly for uneven MTUs:
> 15:16:27.083881 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto SCTP (132), length 1496)
> 10.151.38.153.53417 > 10.151.24.91.54321: sctp (1) [DATA] (B) [TSN: 3077098183] [SID: 0] [SSEQ 1] [PPID 0x0]
> 15:16:27.083907 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto SCTP (132), length 600)
> 10.151.38.153.53417 > 10.151.24.91.54321: sctp (1) [DATA] (E) [TSN: 3077098184] [SID: 0] [SSEQ 1] [PPID 0x0]
> 15:16:27.085640 IP (tos 0x2,ECT(0), ttl 63, id 0, offset 0, flags [DF], proto SCTP (132), length 48)
> 10.151.24.91.54321 > 10.151.38.153.53417: sctp (1) [SACK] [cum ack 3077098184] [a_rwnd 79920] [#gap acks 0] [#dup tsns 0]
>
> The bug was there for years already, but
> - is a performance issue, the packets are still transmitted
> - doesn't show up with default MTU 1500, but possibly with ipsec (MTU 1438)
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nsn.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-vlad
> ---
>
> --- linux-3.10.orig/net/sctp/chunk.c
> +++ linux-3.10/net/sctp/chunk.c
> @@ -200,9 +200,9 @@ struct sctp_datamsg *sctp_datamsg_from_u
> /* This is the biggest possible DATA chunk that can fit into
> * the packet
> */
> - max_data = asoc->pathmtu -
> + max_data = (asoc->pathmtu -
> sctp_sk(asoc->base.sk)->pf->af->net_header_len -
> - sizeof(struct sctphdr) - sizeof(struct sctp_data_chunk);
> + sizeof(struct sctphdr) - sizeof(struct sctp_data_chunk)) & ~3;
>
> max = asoc->frag_point;
> /* If the the peer requested that we authenticate DATA chunks
>
^ permalink raw reply
* Re: VLAN HW accel, performance advantage?
From: Joakim Tjernlund @ 2013-09-03 14:08 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1378216216.1545.1.camel@bwh-desktop.uk.level5networks.com>
Ben Hutchings <bhutchings@solarflare.com> wrote on 2013/09/03 15:50:16:
>
> On Tue, 2013-09-03 at 11:05 +0200, Joakim Tjernlund wrote:
> > I am considering impl. VLAN HW acceleration in Freescales ucc_geth
driver
> > to improve
> > performance, primarily for bridged interfaces.
> > I am hoping the community has some insights as to what performance
gains
> > one
> > could expect?
>
> At the moment you need to do VLAN RX offload (or fake it in software) to
> take advantage of GRO for VLAN-encapsulated packets. Other than that, I
> don't think it makes a lot of difference in most situations.
>
> Ben.
Thanks Ben
I figured one would avoid some memmoves if the tag was extracted and as we
got
a fairly slow CPU (some 300 MHZ MPC 8321) one should gain some performance
but not so then.
I am not familiar with GRO( and its friends) but I am guessing it won't
help
the bridge function or reduce stress from packet storms?
Jocke
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: use reciprocal_divide instead of reimplementing it
From: Eric Dumazet @ 2013-09-03 14:02 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev, netfilter-devel
In-Reply-To: <1378204010-27050-3-git-send-email-dborkman@redhat.com>
On Tue, 2013-09-03 at 12:26 +0200, Daniel Borkmann wrote:
> Replace these places with reciprocal_divide() inline function instead of
> reimplementing it each time, thus it will become easier to read. We do not
> need to explicitly include its header as it's pulled in from linux/net.h
> anyway.
Sure, (((u64) hash * qcount) >> 32) happens to be
reciprocal_divide(hash, qcount) but the result depends on hash being
well distributed in [0 .. ~0U] space.
So 'reciprocal' and 'divide' do not accurately describe this exact
operation.
I suggest making the thing more descriptive.
(And discussed on lkml btw)
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: introduce generic net_random_N helper
From: Eric Dumazet @ 2013-09-03 13:59 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev
In-Reply-To: <1378204010-27050-2-git-send-email-dborkman@redhat.com>
On Tue, 2013-09-03 at 12:26 +0200, Daniel Borkmann wrote:
> We have implemented the same function over and over, so introduce a
> generic helper net_random_N() that unifies these implementations.
> It internally used net_random() which eventually resolves to
> prandom_u32(). Explicit include of reciprocal_div.h is not necessary.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> ---
It was private, so the name was whatever we chose at that time.
If we want to make it generic, why still doing a net_something() ?
Really this patch should be discussed on lkml and netdev and we should
use a generic name.
^ permalink raw reply
* Re: VLAN HW accel, performance advantage?
From: Ben Hutchings @ 2013-09-03 13:50 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OF00E35E7C.7482EC01-ONC1257BDB.00314AD0-C1257BDB.0031F6D0@transmode.se>
On Tue, 2013-09-03 at 11:05 +0200, Joakim Tjernlund wrote:
> I am considering impl. VLAN HW acceleration in Freescales ucc_geth driver
> to improve
> performance, primarily for bridged interfaces.
> I am hoping the community has some insights as to what performance gains
> one
> could expect?
At the moment you need to do VLAN RX offload (or fake it in software) to
take advantage of GRO for VLAN-encapsulated packets. Other than that, I
don't think it makes a lot of difference in most situations.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] rt2x00: Add WLI-UC-G300HP's Product ID
From: Masami Ichikawa @ 2013-09-03 12:51 UTC (permalink / raw)
To: kvalo, IvDoorn, gwingerde, helmut.schaa, linville
Cc: Masami Ichikawa, linux-wireless, users, netdev, linux-kernel
Support Bufallo WLI-UC-G300HP.
Signed-off-by: Masami Ichikawa <masami256@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 840833b..518277d 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -977,6 +977,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x0411, 0x016f) },
{ USB_DEVICE(0x0411, 0x01a2) },
{ USB_DEVICE(0x0411, 0x01ee) },
+ { USB_DEVICE(0x0411, 0x01a8) },
/* Corega */
{ USB_DEVICE(0x07aa, 0x002f) },
{ USB_DEVICE(0x07aa, 0x003c) },
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next 1/2] net: introduce generic net_random_N helper
From: Joe Perches @ 2013-09-03 12:41 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev, Theodore Ts'o
In-Reply-To: <5225D583.9090404@redhat.com>
On Tue, 2013-09-03 at 14:26 +0200, Daniel Borkmann wrote:
> On 09/03/2013 02:15 PM, Joe Perches wrote:
> > I think #define net_random() prandom_u32()
> > should be removed eventually as well.
>
> Why? Assume there could be different PRNGs in future that have different properties
> (e.g. speed vs. period, etc). Then, changing net_random() to something else is way
> easier and less error-prone than searching through the whole subtree of net and
> replacing every occurrence of prandom_u32().
Maybe. There are already instances of prandom_u32
in the net tree. I don't find value in the indirection.
Akinobu Mita once posted a s/net_random/prandom_u32/
patch: https://lkml.org/lkml/2012/12/23/140
> > If gcc doesn't already do this optimization,
> > perhaps there are also some use of
> > net_random() % non_const
> > that could be optimized a bit using this API.
>
> I agree with you, needs to be evaluated on a case by case basis for future work.
__builtin_constant_p is useful.
^ permalink raw reply
* Re: [PATCH v2] ipv6: Don't depend on per socket memory for neighbour discovery messages
From: Thomas Graf @ 2013-09-03 12:11 UTC (permalink / raw)
To: davem, netdev, Eric Dumazet, Stephen Warren, Fabio Estevam
In-Reply-To: <20130903115635.GA21729@order.stressinduktion.org>
On 09/03/13 at 01:56pm, Hannes Frederic Sowa wrote:
> Hi!
>
> On Tue, Sep 03, 2013 at 01:37:01PM +0200, Thomas Graf wrote:
> > @@ -389,6 +386,11 @@ static struct sk_buff *ndisc_alloc_skb(struct net_device *dev,
> > skb_reserve(skb, hlen + sizeof(struct ipv6hdr));
> > skb_reset_transport_header(skb);
> >
> > + /* Manually assign socket ownership as we avoid calling
> > + * sock_alloc_send_pskb() to bypass wmem buffer limits
> > + */
> > + skb_set_owner_w(skb, sk);
> > +
> > return skb;
> > }
>
> Do you know why this is needed? From the report it seemed to me that we might
> have a deadlock on idev->lock and I couldn't find the culprit.
>
> When I tested your change on x86_64 I did not experience this.
I also didn't see any problems running v1 of the patch which
is confusing as the IPv6 output path assumes a socket reference
in various places as Dave pointed out correctly.
I don't see why the problem would be limited to ARM.
> Maybe someone with arm could try this patch with CONFIG_PROVE_LOCKING?
I would certainly welcome that.
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: introduce generic net_random_N helper
From: Daniel Borkmann @ 2013-09-03 12:26 UTC (permalink / raw)
To: Joe Perches; +Cc: davem, netdev, Theodore Ts'o
In-Reply-To: <1378210546.2048.20.camel@joe-AO722>
On 09/03/2013 02:15 PM, Joe Perches wrote:
> On Tue, 2013-09-03 at 13:40 +0200, Daniel Borkmann wrote:
>> On 09/03/2013 01:00 PM, Joe Perches wrote:
>>> On Tue, 2013-09-03 at 12:26 +0200, Daniel Borkmann wrote:
>>>> We have implemented the same function over and over, so introduce a
>>>> generic helper net_random_N() that unifies these implementations.
>>>> It internally used net_random() which eventually resolves to
>>>> prandom_u32(). Explicit include of reciprocal_div.h is not necessary.
>>>
>>> Perhaps adding a generic helper to random.h like
>>> u32 prandom_u32_between(u32 low, u32 high);
>>> or
>>> u32 prandom_u32_range(u32 bound1, u32 bound2)
>>> would be better.
>>
>> Sure, this could be done as a follow-up. Once, we've migrated users to
>> the new API, follow-ups could go ahead to do the rest, and migration
>> will be easy. Note that the lower bound is 0 here.
>
> Part of the reason I suggested this it to make the
> API more readable/intelligible.
>
> At first glance, I have no idea what net_random_N does.
>
> I think #define net_random() prandom_u32()
> should be removed eventually as well.
Why? Assume there could be different PRNGs in future that have different properties
(e.g. speed vs. period, etc). Then, changing net_random() to something else is way
easier and less error-prone than searching through the whole subtree of net and
replacing every occurrence of prandom_u32().
> If gcc doesn't already do this optimization,
> perhaps there are also some use of
> net_random() % non_const
> that could be optimized a bit using this API.
I agree with you, needs to be evaluated on a case by case basis for future work.
> $ git grep -E "(prandom_u32|net_random)\s*\(\s*\)\s*\%" net
> net/batman-adv/bat_iv_ogm.c: msecs += prandom_u32() % (2 * BATADV_JITTER);
> net/batman-adv/bat_iv_ogm.c: return jiffies + msecs_to_jiffies(prandom_u32() % (BATADV_JITTER / 2));
> net/core/neighbour.c: return base ? (net_random() % base) + (base >> 1) : 0;
> net/core/neighbour.c: unsigned long sched_next = now + (net_random() % p->proxy_delay);
> net/core/pktgen.c: flow = prandom_u32() % pkt_dev->cflows;
> net/core/pktgen.c: t = prandom_u32() %
> net/core/pktgen.c: mc = prandom_u32() % pkt_dev->src_mac_count;
> net/core/pktgen.c: mc = prandom_u32() % pkt_dev->dst_mac_count;
> net/core/pktgen.c: pkt_dev->cur_udp_src = prandom_u32() %
> net/core/pktgen.c: pkt_dev->cur_udp_dst = prandom_u32() %
> net/core/pktgen.c: t = prandom_u32() % (imx - imn) + imn;
> net/core/pktgen.c: t = prandom_u32() %
> net/core/pktgen.c: t = prandom_u32() %
> net/core/stream.c: current_timeo = vm_wait = (net_random() % (HZ / 5)) + 2;
> net/ipv4/igmp.c: int tv = net_random() % max_delay;
> net/ipv4/igmp.c: int tv = net_random() % in_dev->mr_maxdelay;
> net/ipv4/igmp.c: int tv = net_random() % delay;
> net/ipv4/inet_connection_sock.c: smallest_rover = rover = net_random() % remaining + low;
> net/ipv6/addrconf.c: rand_num = net_random() % (idev->cnf.rtr_solicit_delay ? : 1);
> net/ipv6/mcast.c: unsigned long tv = net_random() % idev->mc_maxdelay;
> net/ipv6/mcast.c: unsigned long tv = net_random() % delay;
> net/ipv6/mcast.c: unsigned long tv = net_random() % delay;
> net/ipv6/mcast.c: delay = net_random() % resptime;
> net/ipv6/mcast.c: delay = net_random() % unsolicited_report_interval(ma->idev);
> net/netfilter/nf_conntrack_core.c: (prandom_u32() % net->ct.sysctl_events_retry_timeout);
> net/netfilter/nf_conntrack_core.c: (prandom_u32() % net->ct.sysctl_events_retry_timeout);
> net/sched/act_gact.c: if (!gact->tcfg_pval || net_random() % gact->tcfg_pval)
> net/sched/sch_netem.c: skb->data[net_random() % skb_headlen(skb)] ^= 1<<(net_random() % 8);
> net/sctp/socket.c: rover = net_random() % remaining + low;
> net/sunrpc/xprtsock.c: unsigned short rand = (unsigned short) net_random() % range;
> net/xfrm/xfrm_state.c: spi = low + net_random()%(high-low+1);
>
>
^ permalink raw reply
* Re: [PATCH v2 2/2] atm: he: print MAC via %pM
From: Andy Shevchenko @ 2013-09-03 12:25 UTC (permalink / raw)
To: Joe Perches
Cc: Chas Williams, linux-atm-general, inux Net Dev, David S . Miller
In-Reply-To: <1378210806.2048.23.camel@joe-AO722>
On Tue, 2013-09-03 at 05:20 -0700, Joe Perches wrote:
> On Tue, 2013-09-03 at 15:13 +0300, Andy Shevchenko wrote:
> []
> > diff --git a/drivers/atm/he.c b/drivers/atm/he.c
> []
> > @@ -1088,15 +1088,8 @@ static int he_start(struct atm_dev *dev)
> > for (i = 0; i < 6; ++i)
> > dev->esi[i] = read_prom_byte(he_dev, MAC_ADDR + i);
> >
> > - hprintk("%s%s, %x:%x:%x:%x:%x:%x\n",
> > - he_dev->prod_id,
> > - he_dev->media & 0x40 ? "SM" : "MM",
> > - dev->esi[0],
> > - dev->esi[1],
> > - dev->esi[2],
> > - dev->esi[3],
> > - dev->esi[4],
> > - dev->esi[5]);
> > + hprintk("%s%s, %*pM\n", he_dev->prod_id,
> > + he_dev->media & 0x40 ? "SM" : "MM", dev->esi);
>
> %*pM?
>
> Did this compile cleanly?
See v2.1 of this patch, and sorry for this typo.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [PATCH v2 2/2] atm: he: print MAC via %pM
From: Joe Perches @ 2013-09-03 12:20 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Chas Williams, linux-atm-general, inux Net Dev, David S . Miller
In-Reply-To: <1378210424-14781-2-git-send-email-andriy.shevchenko@linux.intel.com>
On Tue, 2013-09-03 at 15:13 +0300, Andy Shevchenko wrote:
[]
> diff --git a/drivers/atm/he.c b/drivers/atm/he.c
[]
> @@ -1088,15 +1088,8 @@ static int he_start(struct atm_dev *dev)
> for (i = 0; i < 6; ++i)
> dev->esi[i] = read_prom_byte(he_dev, MAC_ADDR + i);
>
> - hprintk("%s%s, %x:%x:%x:%x:%x:%x\n",
> - he_dev->prod_id,
> - he_dev->media & 0x40 ? "SM" : "MM",
> - dev->esi[0],
> - dev->esi[1],
> - dev->esi[2],
> - dev->esi[3],
> - dev->esi[4],
> - dev->esi[5]);
> + hprintk("%s%s, %*pM\n", he_dev->prod_id,
> + he_dev->media & 0x40 ? "SM" : "MM", dev->esi);
%*pM?
Did this compile cleanly?
^ permalink raw reply
* Re: [PATCH v2] ipv6: Don't depend on per socket memory for neighbour discovery messages
From: Fabio Estevam @ 2013-09-03 12:18 UTC (permalink / raw)
To: Thomas Graf
Cc: David S. Miller, netdev@vger.kernel.org, Eric Dumazet,
Hannes Frederic Sowa, Stephen Warren
In-Reply-To: <e4600dac657e1160da7a5e7758dcb973b616a10e.1378207925.git.tgraf@suug.ch>
On Tue, Sep 3, 2013 at 8:37 AM, Thomas Graf <tgraf@suug.ch> wrote:
> Allocating skbs when sending out neighbour discovery messages
> currently uses sock_alloc_send_skb() based on a per net namespace
> socket and thus share a socket wmem buffer space.
>
> If a netdevice is temporarily unable to transmit due to carrier
> loss or for other reasons, the queued up ndisc messages will cosnume
> all of the wmem space and will thus prevent from any more skbs to
> be allocated even for netdevices that are able to transmit packets.
>
> The number of neighbour discovery messages sent is very limited,
> use of alloc_skb() bypasses the socket wmem buffer size enforcement
> while the manual call to skb_set_owner_w() maintains the socket
> reference needed for the IPv6 output path.
>
> This patch has orginally been posted by Eric Dumazet in a modified
> form.
>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Fabio Estevam <festevam@gmail.com>
I don't get the system hang that I used to see with the previous
version on my ARM board, so
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
^ permalink raw reply
* [PATCH v2.1] atm: he: print MAC via %pM
From: Andy Shevchenko @ 2013-09-03 12:17 UTC (permalink / raw)
To: Chas Williams, linux-atm-general, netdev, David S . Miller
Cc: Andy Shevchenko
In-Reply-To: <1378210424-14781-2-git-send-email-andriy.shevchenko@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/atm/he.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index 80f9743..8557adc 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -1088,15 +1088,8 @@ static int he_start(struct atm_dev *dev)
for (i = 0; i < 6; ++i)
dev->esi[i] = read_prom_byte(he_dev, MAC_ADDR + i);
- hprintk("%s%s, %x:%x:%x:%x:%x:%x\n",
- he_dev->prod_id,
- he_dev->media & 0x40 ? "SM" : "MM",
- dev->esi[0],
- dev->esi[1],
- dev->esi[2],
- dev->esi[3],
- dev->esi[4],
- dev->esi[5]);
+ hprintk("%s%s, %pM\n", he_dev->prod_id,
+ he_dev->media & 0x40 ? "SM" : "MM", dev->esi);
he_dev->atm_dev->link_rate = he_is622(he_dev) ?
ATM_OC12_PCR : ATM_OC3_PCR;
--
1.8.4.rc3
^ permalink raw reply related
* Re: [PATCH net-next 1/2] net: introduce generic net_random_N helper
From: Joe Perches @ 2013-09-03 12:15 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev, Theodore Ts'o
In-Reply-To: <5225CAB1.7080402@redhat.com>
On Tue, 2013-09-03 at 13:40 +0200, Daniel Borkmann wrote:
> On 09/03/2013 01:00 PM, Joe Perches wrote:
> > On Tue, 2013-09-03 at 12:26 +0200, Daniel Borkmann wrote:
> >> We have implemented the same function over and over, so introduce a
> >> generic helper net_random_N() that unifies these implementations.
> >> It internally used net_random() which eventually resolves to
> >> prandom_u32(). Explicit include of reciprocal_div.h is not necessary.
> >
> > Perhaps adding a generic helper to random.h like
> > u32 prandom_u32_between(u32 low, u32 high);
> > or
> > u32 prandom_u32_range(u32 bound1, u32 bound2)
> > would be better.
>
> Sure, this could be done as a follow-up. Once, we've migrated users to
> the new API, follow-ups could go ahead to do the rest, and migration
> will be easy. Note that the lower bound is 0 here.
Part of the reason I suggested this it to make the
API more readable/intelligible.
At first glance, I have no idea what net_random_N does.
I think #define net_random() prandom_u32()
should be removed eventually as well.
If gcc doesn't already do this optimization,
perhaps there are also some use of
net_random() % non_const
that could be optimized a bit using this API.
$ git grep -E "(prandom_u32|net_random)\s*\(\s*\)\s*\%" net
net/batman-adv/bat_iv_ogm.c: msecs += prandom_u32() % (2 * BATADV_JITTER);
net/batman-adv/bat_iv_ogm.c: return jiffies + msecs_to_jiffies(prandom_u32() % (BATADV_JITTER / 2));
net/core/neighbour.c: return base ? (net_random() % base) + (base >> 1) : 0;
net/core/neighbour.c: unsigned long sched_next = now + (net_random() % p->proxy_delay);
net/core/pktgen.c: flow = prandom_u32() % pkt_dev->cflows;
net/core/pktgen.c: t = prandom_u32() %
net/core/pktgen.c: mc = prandom_u32() % pkt_dev->src_mac_count;
net/core/pktgen.c: mc = prandom_u32() % pkt_dev->dst_mac_count;
net/core/pktgen.c: pkt_dev->cur_udp_src = prandom_u32() %
net/core/pktgen.c: pkt_dev->cur_udp_dst = prandom_u32() %
net/core/pktgen.c: t = prandom_u32() % (imx - imn) + imn;
net/core/pktgen.c: t = prandom_u32() %
net/core/pktgen.c: t = prandom_u32() %
net/core/stream.c: current_timeo = vm_wait = (net_random() % (HZ / 5)) + 2;
net/ipv4/igmp.c: int tv = net_random() % max_delay;
net/ipv4/igmp.c: int tv = net_random() % in_dev->mr_maxdelay;
net/ipv4/igmp.c: int tv = net_random() % delay;
net/ipv4/inet_connection_sock.c: smallest_rover = rover = net_random() % remaining + low;
net/ipv6/addrconf.c: rand_num = net_random() % (idev->cnf.rtr_solicit_delay ? : 1);
net/ipv6/mcast.c: unsigned long tv = net_random() % idev->mc_maxdelay;
net/ipv6/mcast.c: unsigned long tv = net_random() % delay;
net/ipv6/mcast.c: unsigned long tv = net_random() % delay;
net/ipv6/mcast.c: delay = net_random() % resptime;
net/ipv6/mcast.c: delay = net_random() % unsolicited_report_interval(ma->idev);
net/netfilter/nf_conntrack_core.c: (prandom_u32() % net->ct.sysctl_events_retry_timeout);
net/netfilter/nf_conntrack_core.c: (prandom_u32() % net->ct.sysctl_events_retry_timeout);
net/sched/act_gact.c: if (!gact->tcfg_pval || net_random() % gact->tcfg_pval)
net/sched/sch_netem.c: skb->data[net_random() % skb_headlen(skb)] ^= 1<<(net_random() % 8);
net/sctp/socket.c: rover = net_random() % remaining + low;
net/sunrpc/xprtsock.c: unsigned short rand = (unsigned short) net_random() % range;
net/xfrm/xfrm_state.c: spi = low + net_random()%(high-low+1);
^ permalink raw reply
* [PATCH v2 2/2] atm: he: print MAC via %pM
From: Andy Shevchenko @ 2013-09-03 12:13 UTC (permalink / raw)
To: Chas Williams, linux-atm-general, inux Net Dev, David S . Miller
Cc: Andy Shevchenko
In-Reply-To: <1378210424-14781-1-git-send-email-andriy.shevchenko@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/atm/he.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index 80f9743..c232dd3 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -1088,15 +1088,8 @@ static int he_start(struct atm_dev *dev)
for (i = 0; i < 6; ++i)
dev->esi[i] = read_prom_byte(he_dev, MAC_ADDR + i);
- hprintk("%s%s, %x:%x:%x:%x:%x:%x\n",
- he_dev->prod_id,
- he_dev->media & 0x40 ? "SM" : "MM",
- dev->esi[0],
- dev->esi[1],
- dev->esi[2],
- dev->esi[3],
- dev->esi[4],
- dev->esi[5]);
+ hprintk("%s%s, %*pM\n", he_dev->prod_id,
+ he_dev->media & 0x40 ? "SM" : "MM", dev->esi);
he_dev->atm_dev->link_rate = he_is622(he_dev) ?
ATM_OC12_PCR : ATM_OC3_PCR;
--
1.8.4.rc3
^ 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