I note that "proof" is very much in the developer's opinion and
limited testing base.
Actual operational experience, as in a real deployment, with other applications,
heavy context switching, or virtualization, might yield better results.
There's lots of defaults in the linux kernel that are just
tly Linux does not allow this, so this should fail too
> +segmenttest 127.99.4.5 127.99.4.6 16 "assign and ping inside 127/8 (is
> forbidden)"
> +#
> +# Test support for lowest host
> +# Currently Linux does not allow this, so this should fail too
> +segmenttest 5.10.
On Sun, May 10, 2020 at 7:46 AM Jiri Pirko wrote:
>
> Hello guys.
>
> Anyone has any opinion on the proposal? Or should I take it as a silent
> agreement? :)
>
> We would like to go ahead and start sending patchsets.
I gotta say that the whole thing makes my head really hurt, and while
this conve
On Tue, Apr 28, 2020 at 2:10 AM Toke Høiland-Jørgensen wrote:
>
> "Rodney W. Grimes" writes:
>
> > Replying to a single issue I am reading, and really hope I
> > am miss understanding. I am neither a wireguard or linux
> > user so I may be miss understanding what is said.
> >
> > Inline at {RWG}
On Tue, Apr 28, 2020 at 5:06 AM Kalle Valo wrote:
>
> Sven Eckelmann writes:
>
> > On Wednesday, 1 April 2020 09:00:49 CEST Sven Eckelmann wrote:
> >> On Wednesday, 5 February 2020 20:10:43 CEST Linus Lüssing wrote:
> >> > From: Linus Lüssing
> >> >
> >> > Before, only frames with a maximum size
ch a simple patch emerge, openwrt long
ago patched out pfifo_fast. pfifo_fast has
additional semantics not needed in the can use case either (I think)
and "pfifo" is fine, but sure, pfifo_fast if you must.
anyway, regardless, that's an easy fix and I hope this fix goes to
stable, as I've had nightmares about cars exploding due to out of
order can bus operations ever since I learned of this bug.
Acked-by: Dave Taht
--
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
On Mon, Oct 21, 2019 at 4:48 PM Stephen Hemminger
wrote:
>
> On Tue, 1 May 2018 11:32:41 -0700
> Dave Taht wrote:
>
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright 2017 Google Inc.
> > + *
> > + * This program is free software; you
On Wed, Sep 18, 2019 at 7:37 AM Vladimir Oltean wrote:
>
> Hi Sascha,
>
> On Wed, 18 Sep 2019 at 17:03, Sascha Hauer wrote:
> >
> > Hi All,
> >
> > We have a customer using a Marvell 88e6240 switch with Ethercat on one port
> > and
> > regular network traffic on another port. The customer wants
On Fri, Sep 13, 2019 at 9:54 AM Mark Smith wrote:
>
> (Not subscribed to the ML)
>
> Hi,
>
> I've noticed this patch. I don't think it should be applied, as it
> contradicts RFC 1122, "Requirements for Internet Hosts --
> Communication Layers":
Yea! I kicked off a discussion!
> "(g) { 127, }
On Thu, Sep 12, 2019 at 1:59 AM Neal Cardwell wrote:
>
> On Wed, Sep 11, 2019 at 6:32 PM Thomas Higdon wrote:
> >
> > Neal Cardwell mentioned that rcv_wnd would be useful for helping
> > diagnose whether a flow is receive-window-limited at a given instant.
> >
> > This serves the purpose of addin
This patch converts the long "reserved for future use" multicast
address space, 225/8-231/8 - 120m addresses - for use as unicast
addresses instead.
In a comprehensive survey of all the open source code on the planet
we found no users of this range. We found some official and unofficial
usage of a
The 127 concept of "localhost" was basically a straight port over from
original ARPANET behavior. At the time it was envisioned that
many services would exist in the mainframe that would need to be
individually addressable, and long predated alternative approaches
such as tipc, etc.
This reduces
/
talk today.
Dave Taht (2):
Allow 225/8-231/8 as unicast
Reduce localhost to a /16
include/linux/in.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
--
2.17.1
On Mon, Sep 2, 2019 at 8:13 PM David Ahern wrote:
>
> On 9/2/19 4:07 PM, Dave Taht wrote:
> > Windows has the "RtmGetMostSpecificDestination" call:
> > https://docs.microsoft.com/en-us/windows/win32/rras/search-for-the-best-route
> >
> > In particular, I
IN_MULTICAST's primary intent is as a uapi macro.
Elsewhere in the kernel we use ipv4_is_multicast consistently.
This patch unifies linux's multicast checks to use that function
rather than this macro.
Signed-off-by: Dave Taht
Reviewed-by: Toke Høiland-Jørgensen
---
drivers/net/ge
Windows has the "RtmGetMostSpecificDestination" call:
https://docs.microsoft.com/en-us/windows/win32/rras/search-for-the-best-route
In particular, I wanted to search for the best route, AND pick up the
PMTU from that (if it existed)
for older UDP applications like dnssec[1] and newer ones like QUI
On Sun, Aug 25, 2019 at 11:47 PM Eric Dumazet wrote:
>
>
>
> On 8/25/19 7:52 PM, Cong Wang wrote:
> > On Wed, Aug 21, 2019 at 11:00 PM Akshat Kakkar
> > wrote:
> >>
> >> On Thu, Aug 22, 2019 at 3:37 AM Cong Wang wrote:
> I am using ipset + iptables to classify and not filters. Besides, if
On Tue, Aug 27, 2019 at 8:34 AM Eric Dumazet wrote:
>
>
>
> On 8/27/19 4:19 PM, Gautam Ramakrishnan wrote:
> > RFC 8033 suggests an alternative approach to calculate the queue
> > delay in PIE by using per packet timestamps. This patch enables the
> > PIE implementation to do this.
> >
> > The cal
This is vastly improved code, thank you!
1) Since we're still duking it out over the meaning of the bits - not
just the SCE thing, but as best as I can
tell (but could be wrong) the NQB idea wants to put something into the
l4s fast queue? Or is NQB supposed to
be a third queue?
In those cases, th
hange the API, it just stops
tracking a stat and state that is impossible to measure and nobody
uses.
Signed-off-by: Dave Taht
---
net/sched/sch_fq_codel.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/net/sched/sch_fq_codel.c b/net/sched/sch_fq_codel.c
index
: Dave Taht
---
net/sched/sch_fq_codel.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/sched/sch_fq_codel.c b/net/sched/sch_fq_codel.c
index d59fbcc745d1..d67b2c40e6e6 100644
--- a/net/sched/sch_fq_codel.c
+++ b/net/sched/sch_fq_codel.c
@@ -173,6 +173,8 @@ static unsigned int
These two patches improve fq_codel performance
under extreme network loads. The first patch
more rapidly escalates the codel count under
overload, the second just kills a totally useless
statistic.
(sent together because they'd otherwise conflict)
Signed-off-by: Dave Taht
Dave Ta
Does this fix my longstanding issue with piping commands into it? :P
( https://github.com/tohojo/flent/issues/146 )
On Wed, Jul 31, 2019 at 5:46 PM Stephen Hemminger
wrote:
>
> The batchsize feature of tc might save a few cycles but it
> is a maintaince nightmare, it has uninitialized variables
On Mon, Jul 15, 2019 at 11:01 AM Loganaden Velvindron
wrote:
>
> On Fri, Jul 5, 2019 at 6:15 PM Loganaden Velvindron
> wrote:
> >
> > Hi folks,
> >
> > I read the guidelines for LTS/stable.
> > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> >
> >
> > Although this is n
ly
"hot" files - but:
Should Linux treat these ranges as policy, and no longer enforce via
mechanism?
A full patchset for adding 225-232, and 127 address spaces is on github:
https://github.com/dtaht/unicast-extensions
with the very few needed patches for routing daemons and BSD also
available
switches don't care.
0.0.0.0/32 is still prohibited, of course.
Signed-off-by: Dave Taht
Signed-off-by: John Gilmore
Acked-by: Toke Høiland-Jørgensen
---
include/linux/in.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/in.h b/include/linux/in.h
index 4
switches don't care.
0.0.0.0/32 is still prohibited, of course.
Signed-off-by: Dave Taht
---
include/linux/in.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/in.h b/include/linux/in.h
index 4d2fedfb753a..1873ef642605 100644
--- a/include/linux/in.h
hot" files - but:
Should Linux treat these ranges as policy, and no longer enforce via
mechanism?
A full patchset for the remainder of the address spaces is on github:
https://github.com/dtaht/unicast-extensions
with the very few needed patches for routing daemons and BSD also
available
On Mon, Apr 8, 2019 at 7:37 AM Dave Taht wrote:
>
> On Mon, Apr 8, 2019 at 7:31 AM Gautam Ramakrishnan
> wrote:
> >
> > I was trying to refactor the code and I ran into some issues.
> > 1. I moved some of the parameters such as flows_cnt into a new struct
> >
um BYTES ]
> > >> > [ ecn | ecn_prob PERCENTAGE ]
> > >> >
> > >> > defaults: 1024 flows, 10240 packets limit, quantum : device MTU
> > >> >target: 15ms
> > >> >tupdate: 15ms
> > &
Toke Høiland-Jørgensen writes:
> Appana Durga Kedareswara Rao writes:
>
>> Hi Andre,
>>
>>
>>>
>>> On 3/9/19 3:07 PM, Appana Durga Kedareswara rao wrote:
>>> > While stress testing the CAN interface on xilinx axi can in loopback
>>> > mode getting message "write: no buffer space available"
>>
On Mon, Feb 25, 2019 at 4:38 PM Stephen Hemminger
wrote:
>
> On Tue, 26 Feb 2019 00:39:54 +0530
> Leslie Monis wrote:
>
> > The current implementation of the PIE queuing discipline is according to the
> > IETF draft [http://tools.ietf.org/html/draft-pan-aqm-pie-00] and the paper
> > [PIE: A Light
oking[1],
approve of these changes to sch_pie to make it compliant with the rfc,
finally.
[1] We proposed refining pie's ecn handling here:
https://github.com/gautamramk/FQ-PIE-for-Linux-Kernel/issues/2
Anyway:
Acked-by: Dave Taht
David Miller writes:
> From: Dave Taht
> Date: Tue, 11 Dec 2018 15:30:34 -0800
>
>> While most distributions long ago switched to the iproute2 suite
>> of utilities, which allow class-e (240.0.0.0/4) address assignment,
>> distributions relying on busybox, toybox and
decades, and a survey of all the
open source code in the world shows the IN_whatever macros are also
obsolete... rather than obsolete CIDR from this ioctl entirely, this
patch merely enables class-e assignment, sanely.
Signed-off-by: Dave Taht
---
include/uapi/linux/in.h | 10 +++---
net/ipv4
On Mon, Aug 27, 2018 at 9:39 AM Dave Taht wrote:
>
> On Mon, Aug 27, 2018 at 9:11 AM Stephen Hemminger
> wrote:
> >
> > On Sun, 26 Aug 2018 19:42:28 -0700
> > Yousuk Seung wrote:
> >
> > > +int get_time(unsigned int *time, const char *str)
> >
On Mon, Aug 27, 2018 at 9:11 AM Stephen Hemminger
wrote:
>
> On Sun, 26 Aug 2018 19:42:28 -0700
> Yousuk Seung wrote:
>
> > +int get_time(unsigned int *time, const char *str)
> > +{
> > + double t;
> > + char *p;
> > +
> > + t = strtod(str, &p);
> > + if (p == str)
> > +
On Sun, Aug 12, 2018 at 3:09 PM David Ahern wrote:
>
> On 8/6/18 11:09 AM, Yousuk Seung wrote:
> > diff --git a/tc/tc_core.h b/tc/tc_core.h
> > index 1dfa9a4f773b..a0fe0923d171 100644
> > --- a/tc/tc_core.h
> > +++ b/tc/tc_core.h
> > @@ -7,6 +7,10 @@
> >
> > #define TIME_UNITS_PER_SEC 100
>
On Wed, Aug 8, 2018 at 10:00 AM Andrew Lunn wrote:
>
> On Wed, Aug 08, 2018 at 05:27:05PM +0200, Marek Behún wrote:
> > For some reason on Armada 3720 boards (EspressoBin and Turris Mox) the
> > networking driver behaves weirdly when using napi_gro_receive.
> >
> > For example downloading a big fi
On Fri, Aug 3, 2018 at 10:50 AM Matteo Croce wrote:
>
> When 'ip link show dev DEVICE' is processed in a batch mode, ip exits
> and stop processing further commands.
> This because ipaddr_list_flush_or_save() calls exit() to avoid printing
> the link information twice.
> Replace the exit with a cl
ff-by: Dave Taht
---
tc/q_cake.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/tc/q_cake.c b/tc/q_cake.c
index f1e232a..727d673 100644
--- a/tc/q_cake.c
+++ b/tc/q_cake.c
@@ -79,6 +79,7 @@ static void explain(void)
" dual-srchost | dual-dsthost | triple-is
In my dreamworld, a packet with a timestamp achieved at rx time on
ethX, or via local traffic, would be consistent with the right clock
throughout the system and reliably still be there when it goes to
ethY.
This would save having to timestamp (again) inside the cb block in
fq_codel, cake, etc, an
On Tue, Jul 17, 2018 at 2:16 AM Paolo Abeni wrote:
>
> Hi,
>
> On Mon, 2018-07-16 at 16:39 -0700, Cong Wang wrote:
> > On Fri, Jul 13, 2018 at 2:55 AM Paolo Abeni wrote:
> > >
> > > When mirred is invoked from the ingress path, and it wants to redirect
> > > the processed packet, it can now use t
very happy to see this. is there a specific chip or devboard this runs on?
On Tue, Jun 19, 2018 at 11:24 AM, Li Yang wrote:
> On Tue, Jun 19, 2018 at 11:30 AM, Joakim Tjernlund
> wrote:
>> Signed-off-by: Joakim Tjernlund
>
> Acked-by: Li Yang
>
>> ---
>> drivers/net/ethernet/freescale/ucc_get
On Tue, May 1, 2018 at 9:12 PM, David Ahern wrote:
> On 5/1/18 12:32 PM, Dave Taht wrote:
>> ack_recognize can shift pure tcp acks into another flowid.
>> ---
>> examples/bpf/ack_recognize.c | 98
>>
>> 1 file cha
On Tue, May 1, 2018 at 11:53 AM, Toke Høiland-Jørgensen wrote:
> Eric Dumazet writes:
>
>> On 04/30/2018 02:27 PM, Dave Taht wrote:
>>
>>> I actually have a tc - bpf based ack filter, during the development of
>>> cake's ack-thinner, that I should submit
, MA
+ * 02110-1301, USA.
+ */
+
+/*
+ * Author: dave.t...@gmail.com (Dave Taht)
+ *
+ * ack_recognizer: An eBPF program that correctly recognizes modern TCP ACKs,
+ * with tcp option fields like SACK and timestamps, and no additional data.
+ *
+ * ack_match call: Recognize "pure acks" wi
On Mon, Apr 30, 2018 at 2:21 PM, Cong Wang wrote:
> On Sun, Apr 29, 2018 at 2:34 PM, Toke Høiland-Jørgensen wrote:
>> sch_cake targets the home router use case and is intended to squeeze the
>> most bandwidth and latency out of even the slowest ISP links and routers,
>> while presenting an API si
On Tue, Mar 13, 2018 at 11:24 AM, Jakob Unterwurzacher
wrote:
> During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux
> v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction of packets are
> delivered out-of-order.
>
> We have tracked the problem down to the driver int
Mon, Dec 4, 2017 at 2:56 AM, Jesper Dangaard Brouer
wrote:
>
> On Sun, 03 Dec 2017 20:19:33 -0800 Dave Taht wrote:
>
>> Changing the topic, adding bloat.
>
> Adding netdev, and also adjust the topic to be a rant on that the Linux
> kernel network stack is actually da
s.bufferbloat.net mailing list.
Signed-off-by: Dave Taht
---
man/man8/tc-cake.8 | 678 ++
tc/Makefile| 1 +
tc/q_cake.c| 771 +
3 files changed, 1450 insertions(+)
create mode
Add support and man page for cake qdisc.
Dave Taht (1):
Add support for cake qdisc
man/man8/tc-cake.8 | 678 ++
tc/Makefile| 1 +
tc/q_cake.c| 771 +
3 files changed, 1450
Signed-off-by: Dave Taht
---
include/uapi/linux/pkt_sched.h | 58 ++
1 file changed, 58 insertions(+)
diff --git a/include/uapi/linux/pkt_sched.h b/include/uapi/linux/pkt_sched.h
index af3cc2f..ed7c111 100644
--- a/include/uapi/linux/pkt_sched.h
+++ b
s.bufferbloat.net mailing list.
Dave Taht (3):
pkt_sched.h: add support for sch_cake API
Add Common Applications Kept Enhanced (cake) qdisc
Add support for building the new cake qdisc
include/net/cobalt.h | 152 +++
include/uapi/linux/pkt_sched.h | 58 +
net/sched/Kconfig
Hook up sch_cake to the build system.
Signed-off-by: Dave Taht
---
net/sched/Kconfig | 11 +++
net/sched/Makefile | 1 +
2 files changed, 12 insertions(+)
diff --git a/net/sched/Kconfig b/net/sched/Kconfig
index c03d86a..3ea22e5 100644
--- a/net/sched/Kconfig
+++ b/net/sched/Kconfig
16 3
un_flows 0 0 0
max_len 302830283028
Signed-off-by: Dave Taht
Tested-by: Pete Heist
Tested-by: Georgios Amanakis
---
include/net/cobalt.h | 152 +++
net/sched/sch_cake.c | 2561
y 64 bit modulus
>>
>> net/sched/sch_netem.c | 17 +++--
>> 1 file changed, 7 insertions(+), 10 deletions(-)
>>
>
> Acked-by: Randy Dunlap
Acked-by: Dave Taht
Thx.
I have been thinking we'd try to submit sch_cake to mainline on this
go-around. It's been out of tree for way too long.
I look forward to understanding your patches soon in the tbf case.
(I'm only responding because cake uses deficit, rather than a token
bucket, scheduler, and is not reliant on t
On Wed, Nov 8, 2017 at 3:24 PM, Stephen Hemminger
wrote:
> On Wed, 8 Nov 2017 15:12:27 -0800
> Dave Taht wrote:
>
>> --- a/net/sched/sch_netem.c
>> +++ b/net/sched/sch_netem.c
>> @@ -819,6 +819,8 @@ static const struct nla_policy
>> netem_policy[TCA_NETEM_MAX
transition where reducing a tick to nsec
equivalence would constrain the max delay in prior versions of
netem to only 4.3 seconds.
Signed-off-by: Dave Taht
Suggested-by: Eric Dumazet
Reviewed-by: Eric Dumazet
---
include/uapi/linux/pkt_sched.h | 2 ++
net/sched/sch_netem.c | 14 +++
nd,q->slot.slot_next)
Changes since v1:
Always pass new nanosecond APIs to userspace
Dave Taht (3):
netem: convert to qdisc_watchdog_schedule_ns
netem: add uapi to express delay and jitter in nanoseconds
netem: support delivering packets in delayed time slots
include/uapi/linux/pkt_sched
ying rate, and 20ms path
delay:
tc qdisc add dev eth0 root handle 1: netem delay 20ms rate 200mbit \
limit 1
tc qdisc add dev eth0 parent 1:1 handle 10:1 netem delay 200us \
slot 800us 10ms bytes 64k packets 42 limit 512
Signed-off-by: Dave Taht
---
include/uapi/linux/pkt
Upgrade the internal netem scheduler to use nanoseconds rather than
ticks throughout.
Convert to and from the std "ticks" userspace api automatically,
while allowing for finer grained scheduling to take place.
Signed-off-by: Dave Taht
---
net/sched/sch_ne
On Tue, Nov 7, 2017 at 4:26 PM, Stephen Hemminger
wrote:
> On Tue, 7 Nov 2017 12:59:33 -0800
> Dave Taht wrote:
>
>> This patch series converts netem away from the old "ticks" interface and
>> userspace API, and adds support for a new "slot" feature i
ying rate, and 20ms path
delay:
tc qdisc add dev eth0 root handle 1: netem delay 20ms rate 200mbit \
limit 1
tc qdisc add dev eth0 parent 1:1 handle 10:1 netem delay 200us \
slot 800us 10ms bytes 64k packets 42 limit 512
Signed-off-by: Dave Taht
---
include/uapi/linux/pkt
transition where reducing a tick to nsec
equivalence would constrain the max delay in prior versions of
netem to only 4.3 seconds.
Signed-off-by: Dave Taht
---
include/uapi/linux/pkt_sched.h | 2 ++
net/sched/sch_netem.c | 14 ++
2 files changed, 16 insertions(+)
diff --git
This patch series converts netem away from the old "ticks" interface and
userspace API, and adds support for a new "slot" feature intended to
emulate bursty macs such as WiFi and LTE better.
Changes since v1:
Always pass new nanosecond APIs to userspace
Dave Taht (3):
Upgrade the internal netem scheduler to use nanoseconds rather than
ticks throughout.
Convert to and from the std "ticks" userspace api automatically,
while allowing for finer grained scheduling to take place.
Signed-off-by: Dave Taht
---
net/sched/sch_ne
This starts to obsolete the old "ticks" api in favor of well
defined nanoseconds for the kernel/userspace netem interface.
Signed-off-by: Dave Taht
---
tc/q_netem.c | 68 +++-
1 file changed, 44 insertions(+), 24 deletions(-)
di
Signed-off-by: Dave Taht
---
man/man8/tc-netem.8 | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/man/man8/tc-netem.8 b/man/man8/tc-netem.8
index b31384f..8c41d77 100644
--- a/man/man8/tc-netem.8
+++ b/man/man8/tc-netem.8
@@ -8,7 +8,8 @@ NetEm
twork diameters of several hundred light-years. However, only
conversions to and from ns, us, ms, and seconds are provided.
Signed-off-by: Dave Taht
---
tc/tc_core.h | 3 +++
tc/tc_util.c | 56
tc/tc_util.h | 3 +++
3 files change
rate, and 20ms path
delay:
tc qdisc add dev eth0 root handle 1: netem delay 20ms rate 200mbit \
limit 1
tc qdisc add dev eth0 parent 1:1 handle 10:1 netem delay 200us \
slot 800us 10ms bytes 64k packets 42 limit 512
Signed-off-by: Dav
This patch series adds support for specifying time in nanoseconds
to tc, updates netem to use such (requires pkt_sched.h from the kernel
patch series to be imported), and lastly adds a new slotting
feature intended to emulate better how LTE and WiFi work.
Dave Taht (4):
tc: support conversions
Upgrade the internal netem scheduler to use nanoseconds rather than
ticks throughout.
Convert to and from the std "ticks" userspace api automatically,
while allowing for finer grained scheduling to take place.
Signed-off-by: Dave Taht
---
net/sched/sch_ne
This patch series converts netem away from the old "ticks" interface and
userspace API, and adds support for a new "slot" feature intended to
emulate bursty macs such as WiFi and LTE better.
Dave Taht (3):
netem: convert to qdisc_watchdog_schedule_ns
netem: add uapi
ying rate, and 20ms path
delay:
tc qdisc add dev eth0 root handle 1: netem delay 20ms rate 200mbit \
limit 1
tc qdisc add dev eth0 parent 1:1 handle 10:1 netem delay 200us \
slot 800us 10ms bytes 64k packets 42 limit 512
Signed-off-by: Dave Taht
---
include/uapi/linux/pkt
transition where reducing a tick to nsec equivalence
would constrain the max delay in prior versions of netem to only 4.3
seconds.
Signed-off-by: Dave Taht
---
include/uapi/linux/pkt_sched.h | 2 ++
net/sched/sch_netem.c | 16
2 files changed, 18 insertions(+)
diff --git
On Thu, Nov 2, 2017 at 11:09 AM, Cong Wang wrote:
> On Wed, Nov 1, 2017 at 1:17 PM, Dave Taht wrote:
>>
>> That is not in net-next, and the "net" version of that one patch does
>> not apply to net-next. The relevant thread says "... another fun merge
>>
On Wed, Nov 1, 2017 at 9:04 AM, Cong Wang wrote:
> On Tue, Oct 31, 2017 at 11:42 PM, Dave Taht wrote:
>> I am using a fairly complex htb + three tiers of fq_codel and a couple
>> tc filters (it's the sqm-scripts "simple.qos" model). I rebased on
>
I am using a fairly complex htb + three tiers of fq_codel and a couple
tc filters (it's the sqm-scripts "simple.qos" model). I rebased on
net-next head an hour ago, and
[8.357963] IPv6: ADDRCONF(NETDEV_CHANGE): enp2s0: link becomes ready
[9.759942] u32 classifier
[9.759944] Act
On Tue, Jan 10, 2017 at 9:23 AM, Felix Fietkau wrote:
> On 2017-01-10 18:17, Dave Taht wrote:
>> In the case of wifi I have 3 issues with this line of thought.
>>
>> multicast in wifi has generally supposed to be unreliable. This makes
>> it reliable. reliability comes
In the case of wifi I have 3 issues with this line of thought.
multicast in wifi has generally supposed to be unreliable. This makes
it reliable. reliability comes at a cost -
multicast is typically set at a fixed low rate today. unicast is
retried at different rates until it succeeds - for every
The openwrt tree has long contained a set of patches that correct for
unaligned issues throughout the linux network stack.
https://git.lede-project.org/?p=openwrt/source.git;a=blob;f=target/linux/ar71xx/patches-4.4/910-unaligned_access_hacks.patch;h=b4b749e4b9c02a74a9f712a2740d63e554de5c64;hb=ee53
I can't even describe how much I hate the concept of the reorder
buffer in general. Ordering is the endpoints problem.
Someday, after we get fq_codeled, short queues again, I'll be able to show why.
On Mon, May 16, 2016 at 4:41 AM, Luca Coelho wrote:
> On Fri, 2016-05-13 at 11:54 +0300, Dan Carp
On Mon, May 16, 2016 at 1:14 AM, Roman Yeryomin wrote:
> On 16 May 2016 at 01:34, Roman Yeryomin wrote:
>> On 6 May 2016 at 22:43, Dave Taht wrote:
>>> On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin
>>> wrote:
>>>> On 6 May 2016 at 21:43, Roman Yeryom
On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin wrote:
> On 6 May 2016 at 21:43, Roman Yeryomin wrote:
>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer wrote:
>>>
>>> I've created a OpenWRT ticket[1] on this issue, as it seems that someone[2]
>>> closed Felix'es OpenWRT email account (bad choic
I have duplicated the issue on my own hardware. I would like to
explore also upping the codel count in this scenario at some point,
but:
Acked-by: Dave Taht
Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi
put which is
> most likely a result of my sloppy proof-of-concept change in ath10k).
So I should avoid ben greer's firmware for now?
>
>
> Michał
>
> On 16 March 2016 at 20:48, Jasmine Strong wrote:
>> BK usually has 0 txop, so it doesn't do aggregation.
>
it is helpful to name the test files coherently in the flent tests, in
addition to using a directory structure and timestamp. It makes doing
comparison plots in data->add-other-open-data-files simpler. "-t
patched-mac-300mbps", for example.
Also netperf from svn (maybe 2.7, don't remember) will re
>> regular fq_codel uses 1024 and there has not been much reason to
>> change it. In the case of an AP which has more limited memory, 256 or
>> 1024 would be a good setting, per station. I'd stick to 1024 for now.
>
> Do note that the 4096 is shared _across_ station-tid queues. It is not
> per-stat
RANTIES OF MERCHANTABILITY AND FITNESS FOR
> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> + * LIMITED TO, PR
On Mon, Mar 7, 2016 at 9:14 AM, Avery Pennarun wrote:
> On Mon, Mar 7, 2016 at 11:54 AM, Dave Taht wrote:
>> If I can just get a coherent patch set that I can build, I will gladly
>> join you on the testing ath9k in particular... can probably do ath10k,
>> too - and do
If I can just get a coherent patch set that I can build, I will gladly
join you on the testing ath9k in particular... can probably do ath10k,
too - and do a bit of code review... this week. it's very exciting
watching all this activity...
but I confess that I've totally lost track of what set of t
On Tue, Mar 1, 2016 at 11:38 PM, Michal Kazior wrote:
> On 1 March 2016 at 15:02, Johannes Berg wrote:
>> On Fri, 2016-02-26 at 14:09 +0100, Michal Kazior wrote:
>>>
>>> +typedef u64 codel_time_t;
>>
>> Do we really need this? And if yes, does it have to be in the public
>> header file? Why a typ
On Thu, Feb 11, 2016 at 7:29 AM, Grumbach, Emmanuel
wrote:
>
>
> On 02/11/2016 05:12 PM, Eric Dumazet wrote:
>> On Thu, 2016-02-11 at 15:05 +, Grumbach, Emmanuel wrote:
>>
>>
>>> Yeah :) codel_should_drop seemed very long indeed... I wanted to use the
>>> codel_get_time and associated utils (_
On Thu, Feb 11, 2016 at 7:05 AM, Grumbach, Emmanuel
wrote:
> fixing linux-wireless address ...
>
> On 02/11/2016 04:30 PM, Eric Dumazet wrote:
>> On Thu, 2016-02-11 at 16:08 +0200, Emmanuel Grumbach wrote:
>>> Signed-off-by: Emmanuel Grumbach
>>> ---
>>> -static bool codel_should_drop(const struc
> A bursted txop can be as big as 5-10ms. If you consider you want to
> queue 5-10ms worth of data for *each* station at any given time you
> obviously introduce a lot of lag. If you have 10 stations you might
> end up with service period at 10*10ms = 100ms. This gets even worse if
> you consider M
we can get from a few chipsets, but not enough
was known about the iwl last I looked. And one reason why fq_codel -
unassisted - is not quite the right thing on top of this is that
multicast can take a really long time...
Regardless, I'd highly love to see/use this patch myself
On Thu, Jun 4, 2015 at 9:19 AM, Kenneth Klette Jonassen
wrote:
>> why not just call tcp_init_cwnd_reduction()?
>
> I deferred considering the ECN implications of doing so. The code to
> start PRR was based on tcp_enter_cwr()/tcp_init_cwnd_reduction(), save
> that both of these functions ensure a c
100 matches
Mail list logo
