* Re: dynamic TCP algorithms switching
From: Stephen Hemminger @ 2013-11-24 0:42 UTC (permalink / raw)
To: yan cui; +Cc: netdev
In-Reply-To: <CAAVq3rmgzL4Hg__dSkmEM75ZHuEsebE1D4ko-viSEggcYdrPjw@mail.gmail.com>
On Fri, 22 Nov 2013 22:56:10 -0500
yan cui <ccuiyyan@gmail.com> wrote:
> Thanks for the quick reply!
> Do you have the real-world workload results that demonstrate
> that cubic has the best performance among all the available congestion
> algorithms? If so, could you please post some?
>
>
> Thanks, Yan
>
>
> 2013/11/22 Stephen Hemminger <stephen@networkplumber.org>:
> > On Fri, 22 Nov 2013 18:21:12 -0500
> > yan cui <ccuiyyan@gmail.com> wrote:
> >
> >> Then, why include so many (current Linux has 10+ TCP congestion algorithms)
> >> algorithms? For users who want to deploy their application on Linux
> >> and if the applications
> >> are system resource intensive, they always want to tune the
> >> configurations of the operating systems for the last piece of
> >> performance. If they do so, maybe they are confused
> >> about which TCP congestion algorithm to use for their environment. So,
> >> the only way is to try each algorithm one by one. I understand the
> >> setting of the default TCP congestion
> >> algorithm to be Cubic means that it works well for most environments.
> >> But if others
> >> are seldom used, or can be replace with another implementation.
> >> Why not just remove from the kernel?
> >>
> >> Yan
> >
> > Most are intended for research and testing only.
> > Only a few are worth considering in a production environment.
> > That is also why there so many qdisc algorithms as well.
> >
>
>
>
If you did a little searching around, you would find that there has been extensive
research in this area. http://netsrv.csc.ncsu.edu/wiki/index.php/TCP_Testing
is a good place to start.
^ permalink raw reply
* Re: r8169 - it's dead jim
From: Holger Hoffstaette @ 2013-11-24 0:07 UTC (permalink / raw)
To: netdev
In-Reply-To: <529105F8.9030901@nurealm.net>
On Sat, 23 Nov 2013 12:46:00 -0700, James Feeney wrote:
> Going from 3.12.0-1-ARCH to 3.12.1-1-ARCH, the r8169 module is having the
> "link detect" problem again.
3.12.1 didn't contain any r8169 changes, and my cards in 2 different
machines work just fine. Maybe a micro-fractured connector or cable kink?
-h
^ permalink raw reply
* Re: [PATCH] rebalance locks by converting write_lock_bh to write_lock+local_bh_disable
From: Nicholas Mc Guire @ 2013-11-23 23:58 UTC (permalink / raw)
To: David Miller; +Cc: kuznet, eric.dumazet, roque, peterz, netdev
In-Reply-To: <20131123.143929.975712910203893827.davem@davemloft.net>
On Sat, 23 Nov 2013, David Miller wrote:
> From: Nicholas Mc Guire <der.herr@hofr.at>
> Date: Fri, 22 Nov 2013 00:54:02 +0100
>
> > From 2c8e669b691b825c0ed2a02bd7a698d8ed5c6d29 Mon Sep 17 00:00:00 2001
> > From: Nicholas Mc Guire <der.herr@hofr.at>
> > Date: Thu, 21 Nov 2013 18:22:55 -0500
> > Subject: [PATCH] rebalance locks by converting write_lock_bh to write_lock+local_bh_disable
> >
> >
> > in __neigh_event_send write_lock_bh(&neigh->lock) is implicitly balanced by
> > write_unlock(&neigh->lock)+local_bh_disable() - while this is equivalent with
> > respect to the effective low level locking primitives it breaks balancing
> > in the locking api. This makes automatic lock-checking trigger false
> > positives, creates an implicit dependency between *_lock_bh and *_lock
> > functions as well as making the extremly simply locking of net core even
> > easier to understand.
> >
> > The api inbalance was introduced in:
> > commit cd28ca0a3dd17c68d24b839602a0e6268ad28b5d
> > Author: Eric Dumazet <eric.dumazet@gmail.com>
> > This patch just rebalances the lock api
> >
> > No change of functionality
> >
> > Signed-off-by: Nicholas Mc Guire <der.herr@hofr.at>
>
> This is a valid locking idiom, fix the lock checking.
for lock checking that is doable but what is with the api coupling and
readability ?
any change you do to the spin_lock_bh/spin_unlock_bh side would need to also
take care of the spin_lock/spin_unlock variance and keep them functionally
equivalent - currently there is a very small number of such inbalances in
place it seems (scan of 3.12.1 found 1 write_lock/write_lock_bh,
2 spin_lock/spin_lock_bh, 0 in read_lock/read_lock_bh) so is this idiomatic extension sensible given that it introduces implicit api-coupling ?
in one of the cases I do not understand the intent behind the split:
in net/core/sock.c:lock_sock_fast
spin_lock_bh(&sk->sk_lock.slock);
...
spin_unlock(&sk->sk_lock.slock);
/*
* The sk_lock has mutex_lock() semantics here:
*/
mutex_acquire(&sk->sk_lock.dep_map, 0, 0, _RET_IP_);
local_bh_enable();
I think that
spin_lock_bh(&sk->sk_lock.slock);
...
/*
* The sk_lock has mutex_lock() semantics here:
*/
mutex_acquire(&sk->sk_lock.dep_map, 0, 0, _RET_IP_);
spin_unlock_bh(&sk->sk_lock.slock);
should be equivalent ?
thx!
hofrat
^ permalink raw reply
* Re: [PATCH net 0/3] be2net: Patch set
From: David Miller @ 2013-11-23 23:11 UTC (permalink / raw)
To: ajit.khaparde; +Cc: netdev
In-Reply-To: <20131122185055.GA4131@emulex.com>
From: Ajit Khaparde <ajit.khaparde@emulex.com>
Date: Fri, 22 Nov 2013 12:50:55 -0600
> Please apply.
All applied, thanks.
^ permalink raw reply
* Re: Re2: Fw: [Bug 65261] New: Packet loss or excessive packet delay repeatedly for some seconds
From: Arno Wagner @ 2013-11-23 23:01 UTC (permalink / raw)
To: Ben Hutchings, netdev, stephen
In-Reply-To: <20131123221814.GG15822@order.stressinduktion.org>
On Sat, Nov 23, 2013 at 23:18:14 CET, Hannes Frederic Sowa wrote:
> On Sat, Nov 23, 2013 at 11:11:51PM +0100, Arno Wagner wrote:
> > On Sat, Nov 23, 2013 at 21:39:33 CET, Hannes Frederic Sowa wrote:
> > > On Sat, Nov 23, 2013 at 09:20:47PM +0100, Arno Wagner wrote:
> > > > On Sat, Nov 23, 2013 at 17:45:58 CET, Ben Hutchings wrote:
> > > > > On Sat, 2013-11-23 at 13:11 +0100, Arno Wagner wrote:
> > > > > > On Sat, Nov 23, 2013 at 05:33:59 CET, Hannes Frederic Sowa wrote:
> > > > > [...]
> > > > > > > Could you try dropwatch while the packet drops are happening?
> > > > > > > Often it is helpful to check ip monitor all if events happen during bursty
> > > > > > > losses.
> > > > > >
> > > > > > Sorry, but dropwatch is not in Debian and compiling it from sources
> > > > > > seem to require something called "rpmbuild". Hence I cannot use
> > > > > > it or at least would have to write my own Makefile for it.
> > > > >
> > > > > You could use 'perf script net_dropmonitor' instead.
> > > >
> > > > That gets me "invalid or unsupported event: 'skb:kfree_skb'"
> > > > with 3.10.17, so I guess it will not work with 3.10.19 either.
> > >
> > > You need CONFIG_DROP_MONITOR enabled on your kernel build.
> >
> > Found it. At least if it actually is "CONFIG_NET_DROP_MONITOR".
> >
> > Is there any less obscure way than greping the kernel tree and
> > tracing the options back to find out what meny entry turns on
> > what option?
>
> I normally search in menuconfig (press '/').
Thanks, did not know about that one. Looks quite useful.
Anyways, I will run a test with that option and the tool.
in the next few days.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult. --Tony Hoare
^ permalink raw reply
* Re: [PATCH] sit: generate icmpv6 error when receiving icmpv4 error
From: David Miller @ 2013-11-23 22:48 UTC (permalink / raw)
To: ghorbel; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel,
ou.ghorbel
In-Reply-To: <1385133800-1562-1-git-send-email-ghorbel@pivasoftware.com>
From: Oussama Ghorbel <ghorbel@pivasoftware.com>
Date: Fri, 22 Nov 2013 16:23:20 +0100
> Send icmpv6 error with type "destination unreachable" and code
> "address unreachable" when receiving icmpv4 error and sufficient
> data bytes are available
> This patch enhances the compliance of sit tunnel with section 3.4 of
> rfc 4213
>
> Signed-off-by: Oussama Ghorbel <ghorbel@pivasoftware.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: sctp: find the correct highest_new_tsn in sack
From: David Miller @ 2013-11-23 22:46 UTC (permalink / raw)
To: vyasevich; +Cc: changxiangzhong, nhorman, linux-sctp, netdev, linux-kernel
In-Reply-To: <528E85A9.3000703@gmail.com>
From: Vlad Yasevich <vyasevich@gmail.com>
Date: Thu, 21 Nov 2013 17:14:01 -0500
> On 11/21/2013 04:56 PM, Chang Xiangzhong wrote:
>> Function sctp_check_transmitted(transport t, ...) would iterate all of
>> transport->transmitted queue and looking for the highest __newly__ acked tsn.
>> The original algorithm would depend on the order of the assoc->transport_list
>> (in function sctp_outq_sack line 1215 - 1226). The result might not be the
>> expected due to the order of the tranport_list.
>>
>> Solution: checking if the exising is smaller than the new one before assigning
>>
>> Signed-off-by: Chang Xiangzhong <changxiangzhong@gmail.com>
>
> Good find. This has been around for since day 1. It doesn't so much
> depend on the order of the transport list, but on the order the
> transports been used. I agree it is a problem if chunks have been
> distributed across multiple transports and a singe SACK acking them all.
>
> Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [Patch v2] IPv6: Fixed support for blackhole and prohibit routes
From: Hannes Frederic Sowa @ 2013-11-23 22:41 UTC (permalink / raw)
To: Kamala R; +Cc: netdev, David Miller, linux-kernel
In-Reply-To: <1385108488-32163-1-git-send-email-kamala@aristanetwors.com>
On Fri, Nov 22, 2013 at 01:51:28PM +0530, Kamala R wrote:
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index f54e3a1..d90b9ab 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1564,21 +1564,24 @@ int ip6_route_add(struct fib6_config *cfg)
> goto out;
> }
> }
> - rt->dst.output = ip6_pkt_discard_out;
> - rt->dst.input = ip6_pkt_discard;
> rt->rt6i_flags = RTF_REJECT|RTF_NONEXTHOP;
> + rt->dst.error = -ENETUNREACH;
> switch (cfg->fc_type) {
> case RTN_BLACKHOLE:
> rt->dst.error = -EINVAL;
> + rt->dst.output = dst_discard;
> + rt->dst.input = dst_discard;
> break;
> case RTN_PROHIBIT:
> rt->dst.error = -EACCES;
> + rt->dst.output = ip6_pkt_prohibit_out;
> + rt->dst.input = ip6_pkt_prohibit;
> break;
> case RTN_THROW:
> rt->dst.error = -EAGAIN;
> - break;
> default:
> - rt->dst.error = -ENETUNREACH;
> + rt->dst.output = ip6_pkt_discard_out;
> + rt->dst.input = ip6_pkt_discard;
> break;
> }
> goto install_route;
I like it more if a variable is only assigned once. Otherwise it is fine by
me.
^ permalink raw reply
* Re: [PATCH] sch_tbf: handle too small burst
From: David Miller @ 2013-11-23 22:49 UTC (permalink / raw)
To: eric.dumazet; +Cc: yangyingliang, netdev, ben, jpirko, jhs
In-Reply-To: <1385240360.10637.108.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 23 Nov 2013 12:59:20 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> If a too small burst is inadvertently set on TBF, we might trigger
> a bug in tbf_segment(), as 'skb' instead of 'segs' was used in a
> qdisc_reshape_fail() call.
>
> tc qdisc add dev eth0 root handle 1: tbf latency 50ms burst 1KB rate
> 50mbit
>
> Fix the bug, and add a warning, as such configuration is not
> going to work anyway for non GSO packets.
>
> (For some reason, one has to use a burst >= 1520 to get a working
> configuration, even with old kernels. This is a probable iproute2/tc
> bug)
>
> Based on a report and initial patch from Yang Yingliang
>
> Fixes: e43ac79a4bc6 ("sch_tbf: segment too big GSO packets")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Yang Yingliang <yangyingliang@huawei.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] ipv6: fix leaking uninitialized port number of offender sockaddr
From: David Miller @ 2013-11-23 22:49 UTC (permalink / raw)
To: hannes; +Cc: netdev
In-Reply-To: <20131123062233.GD15822@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Sat, 23 Nov 2013 07:22:33 +0100
> Offenders don't have port numbers, so set it to 0.
>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] inet: fix addr_len/msg->msg_namelen assignment in recv_error and rxpmtu functions
From: David Miller @ 2013-11-23 22:49 UTC (permalink / raw)
To: hannes; +Cc: netdev, spender, mpb.mail, eric.dumazet
In-Reply-To: <20131122234612.GB15822@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Sat, 23 Nov 2013 00:46:12 +0100
> Commit bceaa90240b6019ed73b49965eac7d167610be69 ("inet: prevent leakage
> of uninitialized memory to user in recv syscalls") conditionally updated
> addr_len if the msg_name is written to. The recv_error and rxpmtu
> functions relied on the recvmsg functions to set up addr_len before.
>
> As this does not happen any more we have to pass addr_len to those
> functions as well and set it to the size of the corresponding sockaddr
> length.
>
> This broke traceroute and such.
>
> Fixes: bceaa90240b6 ("inet: prevent leakage of uninitialized memory to user in recv syscalls")
> Reported-by: Brad Spengler <spender@grsecurity.net>
> Reported-by: Tom Labanowski
> Cc: mpb <mpb.mail@gmail.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] tcp_memcg: remove useless var old_lim
From: David Miller @ 2013-11-23 22:47 UTC (permalink / raw)
To: gaofeng; +Cc: netdev, glommer
In-Reply-To: <1385102920-31215-1-git-send-email-gaofeng@cn.fujitsu.com>
From: Gao feng <gaofeng@cn.fujitsu.com>
Date: Fri, 22 Nov 2013 14:48:40 +0800
> nobody needs it. remove.
>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Applied.
^ permalink raw reply
* Re: [2/2] gro: Clean up tcpX_gro_receive checksum verification
From: David Miller @ 2013-11-23 22:47 UTC (permalink / raw)
To: eric.dumazet
Cc: herbert, alexander.h.duyck, alexander.duyck, netdev, edumazet
In-Reply-To: <1385099898.10637.75.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 21 Nov 2013 21:58:18 -0800
> On Fri, 2013-11-22 at 10:32 +0800, Herbert Xu wrote:
>> This patch simplifies the checksum verification in tcpX_gro_receive
>> by reusing the CHECKSUM_COMPLETE code for CHECKSUM_NONE. All it
>> does for CHECKSUM_NONE is compute the partial checksum and then
>> treat it as if it came from the hardware (CHECKSUM_COMPLETE).
>>
>> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [1/2] gro: Only verify TCP checksums for candidates
From: David Miller @ 2013-11-23 22:47 UTC (permalink / raw)
To: eric.dumazet
Cc: herbert, alexander.h.duyck, alexander.duyck, netdev, edumazet
In-Reply-To: <1385099712.10637.72.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 21 Nov 2013 21:55:12 -0800
> On Fri, 2013-11-22 at 10:31 +0800, Herbert Xu wrote:
>> In some cases we may receive IP packets that are longer than
>> their stated lengths. Such packets are never merged in GRO.
>> However, we may end up computing their checksums incorrectly
>> and end up allowing packets with a bogus checksum enter our
>> stack with the checksum status set as verified.
>>
>> Since such packets are rare and not performance-critical, this
>> patch simply skips the checksum verification for them.
>>
>> Reported-by: Alexander Duyck <alexander.h.duyck@intel.com>
>> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>> Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Appplied.
^ permalink raw reply
* Re: [PATCH] rebalance locks by converting write_lock_bh to write_lock+local_bh_disable
From: David Miller @ 2013-11-23 22:39 UTC (permalink / raw)
To: der.herr; +Cc: kuznet, eric.dumazet, roque, peterz, netdev
In-Reply-To: <20131121235402.GA11774@opentech.at>
From: Nicholas Mc Guire <der.herr@hofr.at>
Date: Fri, 22 Nov 2013 00:54:02 +0100
> From 2c8e669b691b825c0ed2a02bd7a698d8ed5c6d29 Mon Sep 17 00:00:00 2001
> From: Nicholas Mc Guire <der.herr@hofr.at>
> Date: Thu, 21 Nov 2013 18:22:55 -0500
> Subject: [PATCH] rebalance locks by converting write_lock_bh to write_lock+local_bh_disable
>
>
> in __neigh_event_send write_lock_bh(&neigh->lock) is implicitly balanced by
> write_unlock(&neigh->lock)+local_bh_disable() - while this is equivalent with
> respect to the effective low level locking primitives it breaks balancing
> in the locking api. This makes automatic lock-checking trigger false
> positives, creates an implicit dependency between *_lock_bh and *_lock
> functions as well as making the extremly simply locking of net core even
> easier to understand.
>
> The api inbalance was introduced in:
> commit cd28ca0a3dd17c68d24b839602a0e6268ad28b5d
> Author: Eric Dumazet <eric.dumazet@gmail.com>
> This patch just rebalances the lock api
>
> No change of functionality
>
> Signed-off-by: Nicholas Mc Guire <der.herr@hofr.at>
This is a valid locking idiom, fix the lock checking.
^ permalink raw reply
* Re: Re2: Fw: [Bug 65261] New: Packet loss or excessive packet delay repeatedly for some seconds
From: Hannes Frederic Sowa @ 2013-11-23 22:18 UTC (permalink / raw)
To: Arno Wagner; +Cc: Ben Hutchings, netdev, stephen
In-Reply-To: <20131123221151.GA6365@tansi.org>
On Sat, Nov 23, 2013 at 11:11:51PM +0100, Arno Wagner wrote:
> On Sat, Nov 23, 2013 at 21:39:33 CET, Hannes Frederic Sowa wrote:
> > On Sat, Nov 23, 2013 at 09:20:47PM +0100, Arno Wagner wrote:
> > > On Sat, Nov 23, 2013 at 17:45:58 CET, Ben Hutchings wrote:
> > > > On Sat, 2013-11-23 at 13:11 +0100, Arno Wagner wrote:
> > > > > On Sat, Nov 23, 2013 at 05:33:59 CET, Hannes Frederic Sowa wrote:
> > > > [...]
> > > > > > Could you try dropwatch while the packet drops are happening?
> > > > > > Often it is helpful to check ip monitor all if events happen during bursty
> > > > > > losses.
> > > > >
> > > > > Sorry, but dropwatch is not in Debian and compiling it from sources
> > > > > seem to require something called "rpmbuild". Hence I cannot use
> > > > > it or at least would have to write my own Makefile for it.
> > > >
> > > > You could use 'perf script net_dropmonitor' instead.
> > >
> > > That gets me "invalid or unsupported event: 'skb:kfree_skb'"
> > > with 3.10.17, so I guess it will not work with 3.10.19 either.
> >
> > You need CONFIG_DROP_MONITOR enabled on your kernel build.
>
> Found it. At least if it actually is "CONFIG_NET_DROP_MONITOR".
>
> Is there any less obscure way than greping the kernel tree and
> tracing the options back to find out what meny entry turns on
> what option?
I normally search in menuconfig (press '/').
^ permalink raw reply
* Re: Fw: [Bug 65261] New: Packet loss or excessive packet delay repeatedly for some seconds
From: Hannes Frederic Sowa @ 2013-11-23 22:17 UTC (permalink / raw)
To: Arno Wagner; +Cc: Ben Hutchings, netdev, stephen
In-Reply-To: <20131123215959.GA2570@tansi.org>
On Sat, Nov 23, 2013 at 11:00:00PM +0100, Arno Wagner wrote:
> On Sat, Nov 23, 2013 at 21:39:33 CET, Hannes Frederic Sowa wrote:
> > On Sat, Nov 23, 2013 at 09:20:47PM +0100, Arno Wagner wrote:
> > > On Sat, Nov 23, 2013 at 17:45:58 CET, Ben Hutchings wrote:
> > > > On Sat, 2013-11-23 at 13:11 +0100, Arno Wagner wrote:
> > > > > On Sat, Nov 23, 2013 at 05:33:59 CET, Hannes Frederic Sowa wrote:
> > > > [...]
> > > > > > Could you try dropwatch while the packet drops are happening?
> > > > > > Often it is helpful to check ip monitor all if events happen during bursty
> > > > > > losses.
> > > > >
> > > > > Sorry, but dropwatch is not in Debian and compiling it from sources
> > > > > seem to require something called "rpmbuild". Hence I cannot use
> > > > > it or at least would have to write my own Makefile for it.
> > > >
> > > > You could use 'perf script net_dropmonitor' instead.
> > >
> > > That gets me "invalid or unsupported event: 'skb:kfree_skb'"
> > > with 3.10.17, so I guess it will not work with 3.10.19 either.
> >
> > You need CONFIG_DROP_MONITOR enabled on your kernel build.
>
> Interestingly, that option is not even there in .config.
> Must be someting that "make oldconfig" messed up along
> the way, as making a new .config with all default values
> does have it commented out as "not set".
>
> After a bit of poking around, I found it and its pre-requisites
> net/Kconfig, where it says it depends on INET && TRACEPOINTS.
> After a bit more poking I finally found TRACEPOINTS on init/Kconfig,
> depending on nothing. But it does not get displayed as selectable
> in "make menuconfig". As far as I can tell, it is not constrained
> and should show up?
>
> So I really have no clue how to turn this on...
Check Kernel Hacking -> Tracers. It should show up Networking options ->
Network testing.
Greetings,
Hannes
^ permalink raw reply
* Re2: Fw: [Bug 65261] New: Packet loss or excessive packet delay repeatedly for some seconds
From: Arno Wagner @ 2013-11-23 22:11 UTC (permalink / raw)
To: Ben Hutchings, netdev, stephen
In-Reply-To: <20131123203933.GE15822@order.stressinduktion.org>
On Sat, Nov 23, 2013 at 21:39:33 CET, Hannes Frederic Sowa wrote:
> On Sat, Nov 23, 2013 at 09:20:47PM +0100, Arno Wagner wrote:
> > On Sat, Nov 23, 2013 at 17:45:58 CET, Ben Hutchings wrote:
> > > On Sat, 2013-11-23 at 13:11 +0100, Arno Wagner wrote:
> > > > On Sat, Nov 23, 2013 at 05:33:59 CET, Hannes Frederic Sowa wrote:
> > > [...]
> > > > > Could you try dropwatch while the packet drops are happening?
> > > > > Often it is helpful to check ip monitor all if events happen during bursty
> > > > > losses.
> > > >
> > > > Sorry, but dropwatch is not in Debian and compiling it from sources
> > > > seem to require something called "rpmbuild". Hence I cannot use
> > > > it or at least would have to write my own Makefile for it.
> > >
> > > You could use 'perf script net_dropmonitor' instead.
> >
> > That gets me "invalid or unsupported event: 'skb:kfree_skb'"
> > with 3.10.17, so I guess it will not work with 3.10.19 either.
>
> You need CONFIG_DROP_MONITOR enabled on your kernel build.
Found it. At least if it actually is "CONFIG_NET_DROP_MONITOR".
Is there any less obscure way than greping the kernel tree and
tracing the options back to find out what meny entry turns on
what option?
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult. --Tony Hoare
^ permalink raw reply
* Re: Fw: [Bug 65261] New: Packet loss or excessive packet delay repeatedly for some seconds
From: Arno Wagner @ 2013-11-23 22:00 UTC (permalink / raw)
To: Ben Hutchings, netdev, stephen
In-Reply-To: <20131123203933.GE15822@order.stressinduktion.org>
On Sat, Nov 23, 2013 at 21:39:33 CET, Hannes Frederic Sowa wrote:
> On Sat, Nov 23, 2013 at 09:20:47PM +0100, Arno Wagner wrote:
> > On Sat, Nov 23, 2013 at 17:45:58 CET, Ben Hutchings wrote:
> > > On Sat, 2013-11-23 at 13:11 +0100, Arno Wagner wrote:
> > > > On Sat, Nov 23, 2013 at 05:33:59 CET, Hannes Frederic Sowa wrote:
> > > [...]
> > > > > Could you try dropwatch while the packet drops are happening?
> > > > > Often it is helpful to check ip monitor all if events happen during bursty
> > > > > losses.
> > > >
> > > > Sorry, but dropwatch is not in Debian and compiling it from sources
> > > > seem to require something called "rpmbuild". Hence I cannot use
> > > > it or at least would have to write my own Makefile for it.
> > >
> > > You could use 'perf script net_dropmonitor' instead.
> >
> > That gets me "invalid or unsupported event: 'skb:kfree_skb'"
> > with 3.10.17, so I guess it will not work with 3.10.19 either.
>
> You need CONFIG_DROP_MONITOR enabled on your kernel build.
Interestingly, that option is not even there in .config.
Must be someting that "make oldconfig" messed up along
the way, as making a new .config with all default values
does have it commented out as "not set".
After a bit of poking around, I found it and its pre-requisites
net/Kconfig, where it says it depends on INET && TRACEPOINTS.
After a bit more poking I finally found TRACEPOINTS on init/Kconfig,
depending on nothing. But it does not get displayed as selectable
in "make menuconfig". As far as I can tell, it is not constrained
and should show up?
So I really have no clue how to turn this on...
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult. --Tony Hoare
^ permalink raw reply
* Re: [OOPS][3.12] BUG: unable to handle kernel NULL pointer dereference at 0000000c
From: Kirill A. Shutemov @ 2013-11-23 21:10 UTC (permalink / raw)
To: Steffen Klassert
Cc: David Miller, pomac, bhelgaas, pomac, linux-kernel, edumazet,
netdev, alex.aring, stable
In-Reply-To: <20131118092255.GX31491@secunet.com>
On Mon, Nov 18, 2013 at 10:22:55AM +0100, Steffen Klassert wrote:
> On Fri, Nov 15, 2013 at 06:57:55PM -0500, David Miller wrote:
> > From: Ian Kumlien <pomac@demius.net>
> > Date: Sat, 16 Nov 2013 00:39:19 +0100
> >
> > > On Fri, Nov 15, 2013 at 05:44:26PM -0500, David Miller wrote:
> > >> From: Bjorn Helgaas <bhelgaas@google.com>
> > >> Date: Fri, 15 Nov 2013 15:29:53 -0700
> > >>
> > >> > [+cc David, Eric, Alex, netdev]
> > >> >
> > >> > Alex reported a similar issue at
> > >> > http://marc.info/?l=linux-netdev&m=138355719901790&w=4
> > >>
> > >> Fixed by:
> > >>
> > >> commit 84502b5ef9849a9694673b15c31bd3ac693010ae
> > >> Author: Steffen Klassert <steffen.klassert@secunet.com>
> > >> Date: Wed Oct 30 11:16:28 2013 +0100
> > >
> > > Cherry-picked, compiled and preparing for reboot - thanks!
> > >
> > > Shouldn't this be queued up in stable sometime soonish?
> > >
> > > (Sorry for the change of email address, i had forgot to switch the
> > > configurations in mutt)
> >
> > Steffen is in charge of IPSEC -stable submissions, please ask him
> > :-)
>
> It was intended for v3.12 but the release came before it was merged
> into the manline. So yes, it should go to the v3.12 stable tree.
>
> I've always did stable submissions just by marking them as a
> candidate for stable, this did not happen here because I hoped
> it will make it into v3.12. It should apply cleanly to v3.12
> stable, you could just pick it into you stable queue, or
> alternatively I can submit to stable.
Any progress with getting the patch into stable?
It's not in v3.12.1 and I don't see it in stable queue.
--
Kirill A. Shutemov
^ permalink raw reply
* [PATCH] sch_tbf: handle too small burst
From: Eric Dumazet @ 2013-11-23 20:59 UTC (permalink / raw)
To: Yang Yingliang, David Miller; +Cc: netdev, ben, jpirko, jhs
In-Reply-To: <1385229367.10637.92.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
If a too small burst is inadvertently set on TBF, we might trigger
a bug in tbf_segment(), as 'skb' instead of 'segs' was used in a
qdisc_reshape_fail() call.
tc qdisc add dev eth0 root handle 1: tbf latency 50ms burst 1KB rate
50mbit
Fix the bug, and add a warning, as such configuration is not
going to work anyway for non GSO packets.
(For some reason, one has to use a burst >= 1520 to get a working
configuration, even with old kernels. This is a probable iproute2/tc
bug)
Based on a report and initial patch from Yang Yingliang
Fixes: e43ac79a4bc6 ("sch_tbf: segment too big GSO packets")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Yang Yingliang <yangyingliang@huawei.com>
---
Note : I prepared a self contained patch for the ease of stable
submissions. We might later move skb_gso_seglen() in an
include file.
net/sched/sch_tbf.c | 32 +++++++++++++++++++++++++-------
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/net/sched/sch_tbf.c b/net/sched/sch_tbf.c
index 68f9859..a609005 100644
--- a/net/sched/sch_tbf.c
+++ b/net/sched/sch_tbf.c
@@ -21,6 +21,7 @@
#include <net/netlink.h>
#include <net/sch_generic.h>
#include <net/pkt_sched.h>
+#include <net/tcp.h>
/* Simple Token Bucket Filter.
@@ -117,6 +118,22 @@ struct tbf_sched_data {
};
+/*
+ * Return length of individual segments of a gso packet,
+ * including all headers (MAC, IP, TCP/UDP)
+ */
+static unsigned int skb_gso_seglen(const struct sk_buff *skb)
+{
+ unsigned int hdr_len = skb_transport_header(skb) - skb_mac_header(skb);
+ const struct skb_shared_info *shinfo = skb_shinfo(skb);
+
+ if (likely(shinfo->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6)))
+ hdr_len += tcp_hdrlen(skb);
+ else
+ hdr_len += sizeof(struct udphdr);
+ return hdr_len + shinfo->gso_size;
+}
+
/* GSO packet is too big, segment it so that tbf can transmit
* each segment in time
*/
@@ -136,12 +153,8 @@ static int tbf_segment(struct sk_buff *skb, struct Qdisc *sch)
while (segs) {
nskb = segs->next;
segs->next = NULL;
- if (likely(segs->len <= q->max_size)) {
- qdisc_skb_cb(segs)->pkt_len = segs->len;
- ret = qdisc_enqueue(segs, q->qdisc);
- } else {
- ret = qdisc_reshape_fail(skb, sch);
- }
+ qdisc_skb_cb(segs)->pkt_len = segs->len;
+ ret = qdisc_enqueue(segs, q->qdisc);
if (ret != NET_XMIT_SUCCESS) {
if (net_xmit_drop_count(ret))
sch->qstats.drops++;
@@ -163,7 +176,7 @@ static int tbf_enqueue(struct sk_buff *skb, struct Qdisc *sch)
int ret;
if (qdisc_pkt_len(skb) > q->max_size) {
- if (skb_is_gso(skb))
+ if (skb_is_gso(skb) && skb_gso_seglen(skb) <= q->max_size)
return tbf_segment(skb, sch);
return qdisc_reshape_fail(skb, sch);
}
@@ -319,6 +332,11 @@ static int tbf_change(struct Qdisc *sch, struct nlattr *opt)
if (max_size < 0)
goto done;
+ if (max_size < psched_mtu(qdisc_dev(sch)))
+ pr_warn_ratelimited("sch_tbf: burst %u is lower than device %s mtu (%u) !\n",
+ max_size, qdisc_dev(sch)->name,
+ psched_mtu(qdisc_dev(sch)));
+
if (q->qdisc != &noop_qdisc) {
err = fifo_set_limit(q->qdisc, qopt->limit);
if (err)
^ permalink raw reply related
* Re: Fw: [Bug 65261] New: Packet loss or excessive packet delay repeatedly for some seconds
From: Hannes Frederic Sowa @ 2013-11-23 20:39 UTC (permalink / raw)
To: Arno Wagner; +Cc: Ben Hutchings, netdev, stephen
In-Reply-To: <20131123202046.GB715@tansi.org>
On Sat, Nov 23, 2013 at 09:20:47PM +0100, Arno Wagner wrote:
> On Sat, Nov 23, 2013 at 17:45:58 CET, Ben Hutchings wrote:
> > On Sat, 2013-11-23 at 13:11 +0100, Arno Wagner wrote:
> > > On Sat, Nov 23, 2013 at 05:33:59 CET, Hannes Frederic Sowa wrote:
> > [...]
> > > > Could you try dropwatch while the packet drops are happening?
> > > > Often it is helpful to check ip monitor all if events happen during bursty
> > > > losses.
> > >
> > > Sorry, but dropwatch is not in Debian and compiling it from sources
> > > seem to require something called "rpmbuild". Hence I cannot use
> > > it or at least would have to write my own Makefile for it.
> >
> > You could use 'perf script net_dropmonitor' instead.
>
> That gets me "invalid or unsupported event: 'skb:kfree_skb'"
> with 3.10.17, so I guess it will not work with 3.10.19 either.
You need CONFIG_DROP_MONITOR enabled on your kernel build.
^ permalink raw reply
* Re: Fw: [Bug 65261] New: Packet loss or excessive packet delay repeatedly for some seconds
From: Ben Hutchings @ 2013-11-23 20:31 UTC (permalink / raw)
To: Arno Wagner; +Cc: netdev, stephen
In-Reply-To: <20131123202046.GB715@tansi.org>
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
On Sat, 2013-11-23 at 21:20 +0100, Arno Wagner wrote:
> On Sat, Nov 23, 2013 at 17:45:58 CET, Ben Hutchings wrote:
> > On Sat, 2013-11-23 at 13:11 +0100, Arno Wagner wrote:
> > > On Sat, Nov 23, 2013 at 05:33:59 CET, Hannes Frederic Sowa wrote:
> > [...]
> > > > Could you try dropwatch while the packet drops are happening?
> > > > Often it is helpful to check ip monitor all if events happen during bursty
> > > > losses.
> > >
> > > Sorry, but dropwatch is not in Debian and compiling it from sources
> > > seem to require something called "rpmbuild". Hence I cannot use
> > > it or at least would have to write my own Makefile for it.
> >
> > You could use 'perf script net_dropmonitor' instead.
>
> That gets me "invalid or unsupported event: 'skb:kfree_skb'"
> with 3.10.17, so I guess it will not work with 3.10.19 either.
That is probably an obscure way of saying 'permission denied'; I see the
same if I don't run it as root.
Ben.
--
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: Fw: [Bug 65261] New: Packet loss or excessive packet delay repeatedly for some seconds
From: Arno Wagner @ 2013-11-23 20:20 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, stephen
In-Reply-To: <1385225158.20467.70.camel@deadeye.wl.decadent.org.uk>
On Sat, Nov 23, 2013 at 17:45:58 CET, Ben Hutchings wrote:
> On Sat, 2013-11-23 at 13:11 +0100, Arno Wagner wrote:
> > On Sat, Nov 23, 2013 at 05:33:59 CET, Hannes Frederic Sowa wrote:
> [...]
> > > Could you try dropwatch while the packet drops are happening?
> > > Often it is helpful to check ip monitor all if events happen during bursty
> > > losses.
> >
> > Sorry, but dropwatch is not in Debian and compiling it from sources
> > seem to require something called "rpmbuild". Hence I cannot use
> > it or at least would have to write my own Makefile for it.
>
> You could use 'perf script net_dropmonitor' instead.
That gets me "invalid or unsupported event: 'skb:kfree_skb'"
with 3.10.17, so I guess it will not work with 3.10.19 either.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult. --Tony Hoare
^ permalink raw reply
* r8169 - it's dead jim
From: James Feeney @ 2013-11-23 19:46 UTC (permalink / raw)
To: Realtek and the Linux r8169 crew
Hey
Going from 3.12.0-1-ARCH to 3.12.1-1-ARCH, the r8169 module is having the "link
detect" problem again.
Initially, "ethtool -s <blah> autoneg off" gives "invalid argument".
"sudo mii-tool -R enp22s0" - Reset the MII to its default configuration - will
allow a 10Mb/s half duplex connection, with "autoneg off".
"ethtool -s <blah> autoneg off" then will work, after the "mii-tool -R <blah>".
After some time, Auto-negotiation will spontaneously go on, and a 100Mb/s full
duplex connection will come up, on a 1Gb/s interface. Subsequent unplugging and
plugging the cable gives a 1Gb/s full duplex connection.
This problem has been recurring for so many years, I hope the solution is
something obvious, perhaps a recent change to the kernel?
Thanks
James
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox