Re: [RFC PATCH net-next] tcp: add CDG congestion control

On Thu, Jun 4, 2015 at 9:19 AM, Kenneth Klette Jonassen kenne...@ifi.uio.no 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

Re: [RFC RESEND] iwlwifi: pcie: transmit queue auto-sizing

e 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 in a variety of real w

Re: [RFC v2] iwlwifi: pcie: transmit queue auto-sizing

> 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

Re: [PATCH] codel: add forgotten inline to functions in header file

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

Re: [PATCH] codel: add forgotten inline to functions in header file

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 >>>

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

>> 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 >

Re: [RFCv2 0/3] mac80211: implement fq codel

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: [RFCv2 0/3] mac80211: implement fq codel

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 <j...@eero.com> wrote: >> BK usually has 0 txop, so it doesn't do aggregation. >> >> On Wed, Mar

8:25 arriving 9:07, if I catch it....

Dave Täht Let's go make home routers and wifi faster! With better software! https://www.gofundme.com/savewifi

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

On Mon, Mar 7, 2016 at 9:14 AM, Avery Pennarun <apenw...@gmail.com> wrote: > On Mon, Mar 7, 2016 at 11:54 AM, Dave Taht <dave.t...@gmail.com> wrote: >> If I can just get a coherent patch set that I can build, I will gladly >> join you on the testing ath9k in particula

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

RESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > + * LIMITED TO, THE IMPLIED WARRANTIES 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, > + * SPECI

Re: OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)

On Mon, May 16, 2016 at 1:14 AM, Roman Yeryomin <leroi.li...@gmail.com> wrote: > On 16 May 2016 at 01:34, Roman Yeryomin <leroi.li...@gmail.com> wrote: >> On 6 May 2016 at 22:43, Dave Taht <dave.t...@gmail.com> wrote: >>> On Fri, May 6, 2016 at 11:56 AM, R

Re: iwlwifi: mvm: add reorder buffer per queue

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

Re: OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)

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

Re: [PATCH net-next] fq_codel: add batch ability to fq_codel_drop()

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

Re: Misalignment, MIPS, and ip_hdr(skb)->version

The openwrt tree has long contained a set of patches that correct for unaligned issues throughout the linux network stack.

Re: [PATCH net-next] bridge: multicast to unicast

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

Re: [PATCH net-next] bridge: multicast to unicast

On Tue, Jan 10, 2017 at 9:23 AM, Felix Fietkau <n...@nbd.name> 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 reli

Re: [PATCH net-next v2 0/2] netem: fix compilation on 32 bit

> netem: remove unnecessary 64 bit modulus >> >> net/sched/sch_netem.c | 17 +++-- >> 1 file changed, 7 insertions(+), 10 deletions(-) >> > > Acked-by: Randy Dunlap <rdun...@infradead.org> Acked-by: Dave Taht <dave.t...@gmail.com> Thx.

[PATCH iproute2 net-next] Add support and man page for cake qdisc

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

[PATCH net-next 3/3] Add support for building the new cake qdisc

Hook up sch_cake to the build system. Signed-off-by: Dave Taht <dave.t...@gmail.com> --- 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/K

[PATCH net-next 2/3] Add Common Applications Kept Enhanced (cake) qdisc

3 un_flows 0 0 0 max_len 302830283028 Signed-off-by: Dave Taht <dave.t...@gmail.com> Tested-by: Pete Heist <petehe...@gmail.com> Tested-by: Georgios Amanakis <gamana...@gmail.com> --- include/net/cobalt.h |

[PATCH net-next 1/3] pkt_sched.h: add support for sch_cake API

Signed-off-by: Dave Taht <dave.t...@gmail.com> --- 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

[PATCH net-next 0/3] Add Common Applications Kept Enhanced (cake) qdisc

ferbloat.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

[PATCH iproute2 net-next] Add support for cake qdisc

ferbloat.net mailing list. Signed-off-by: Dave Taht <dave.t...@gmail.com> --- man/man8/tc-cake.8 | 678 ++ tc/Makefile| 1 + tc/q_cake.c| 771 + 3 files changed, 1450 insertions(

Re: Per-CPU Queueing for QoS

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

Re: Oops with HTB on net-next

On Wed, Nov 1, 2017 at 9:04 AM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > On Tue, Oct 31, 2017 at 11:42 PM, Dave Taht <dave.t...@gmail.com> wrote: >> I am using a fairly complex htb + three tiers of fq_codel and a couple >> tc filters (it's the sqm-scripts &qu

Re: Oops with HTB on net-next

On Thu, Nov 2, 2017 at 11:09 AM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > On Wed, Nov 1, 2017 at 1:17 PM, Dave Taht <dave.t...@gmail.com> wrote: >> >> That is not in net-next, and the "net" version of that one patch does >> not apply to net-next

[PATCH net-next 2/3] netem: add uapi to express delay and jitter in nanosec

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 <dave.t...@gmail.com> --- include/uapi/linux/pkt_sched.h | 2 ++ net/sched/sch_netem.c | 16 2 files change

[PATCH iproute2 1/4] tc: support conversions to or from 64 bit nanosecond-based time

diameters of several hundred light-years. However, only conversions to and from ns, us, ms, and seconds are provided. Signed-off-by: Dave Taht <dave.t...@gmail.com> --- tc/tc_core.h | 3 +++ tc/tc_util.c | 56 tc/tc_util.h | 3

[PATCH iproute2 3/4] q_netem: support delivering packets in delayed time slots

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 <dave.t...@

[PATCH iproute2 2/4] q_netem: utilize 64 bit nanosecond API for delay and jitter

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 <dave.t...@gmail.com> --- tc/q_netem.c | 68 +++- 1 file changed, 44 i

[PATCH iproute2 4/4] netem: add documentation for the new slotting feature

Signed-off-by: Dave Taht <dave.t...@gmail.com> --- 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-n

[PATCH iproute2 0/4] support nsec uapi and add netem slotting feature

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

[PATCH net-next 3/3] netem: support delivering packets in delayed time slots

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 <dave.t...@gmail.com> ---

[PATCH net-next 1/3] netem: convert to qdisc_watchdog_schedule_ns

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 <dave.t...@gmail.com> --- net/sched/

[PATCH net-next 0/3] netem: add nsec scheduling and slot feature

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 u

[PATCH v2 net-next 0/3] netem: add nsec scheduling and slot feature

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 (

Re: [PATCH net-next 0/3] netem: add nsec scheduling and slot feature

On Tue, Nov 7, 2017 at 4:26 PM, Stephen Hemminger <step...@networkplumber.org> wrote: > On Tue, 7 Nov 2017 12:59:33 -0800 > Dave Taht <dave.t...@gmail.com> wrote: > >> This patch series converts netem away from the old "ticks" interface and >> user

[PATCH v2 net-next 1/3] netem: convert to qdisc_watchdog_schedule_ns

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 <dave.t...@gmail.com> --- net/sched/

Re: [PATCH v3 net-next 2/3] netem: add uapi to express delay and jitter in nanoseconds

On Wed, Nov 8, 2017 at 3:24 PM, Stephen Hemminger <step...@networkplumber.org> wrote: > On Wed, 8 Nov 2017 15:12:27 -0800 > Dave Taht <dave.t...@gmail.com> wrote: > >> --- a/net/sched/sch_netem.c >> +++ b/net/sched/sch_netem.c >> @@ -819,6 +819,8 @@ static c

[PATCH v3 net-next 3/3] netem: support delivering packets in delayed time slots

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 <dave.t...@gmail.com> ---

[PATCH v3 net-next 1/3] netem: convert to qdisc_watchdog_schedule_ns

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 <dave.t...@gmail.com> --- net/sched/

[PATCH v3 net-next 0/3] netem: add nsec scheduling and slot feature

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

[PATCH v3 net-next 2/3] netem: add uapi to express delay and jitter in nanoseconds

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 <dave.t...@gmail.com> Suggested-by: Eric Dumazet <eduma...@google.com> Reviewed-by: Eric Dumazet <eduma...@google.com> --- in

[PATCH v2 net-next 3/3] netem: support delivering packets in delayed time slots

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 <dave.t...@gmail.com> ---

[PATCH v2 net-next 2/3] netem: add uapi to express delay and jitter in nanoseconds

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 <dave.t...@gmail.com> --- include/uapi/linux/pkt_sched.h | 2 ++ net/sched/sch_netem.c | 14 ++ 2 files change

Re: [Bloat] Linux network is damn fast, need more use XDP (Was: DC behaviors today)

, 2017 at 2:56 AM, Jesper Dangaard Brouer <bro...@redhat.com> wrote: > > On Sun, 03 Dec 2017 20:19:33 -0800 Dave Taht <d...@taht.net> wrote: > >> Changing the topic, adding bloat. > > Adding netdev, and also adjust the topic to be a rant on that the Linux > kernel

Oops with HTB on net-next

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]

Re: [PATCH] ucc_geth: Add BQL support

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 > >> --- >>

Re: [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc

On Tue, May 1, 2018 at 11:53 AM, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > Eric Dumazet <eric.duma...@gmail.com> writes: > >> On 04/30/2018 02:27 PM, Dave Taht wrote: >> >>> I actually have a tc - bpf based ack filter, during the development of >>&

Re: [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc

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

[PATCH iproute2-next] Add tc-BPF example for a TCP pure ack recognizer

, 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

Re: [PATCH iproute2-next] Add tc-BPF example for a TCP pure ack recognizer

On Tue, May 1, 2018 at 9:12 PM, David Ahern <dsah...@gmail.com> 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 >> ++

Re: [PATCH iproute2] ip link: don't stop batch processing

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

[PATCH iproute2-next] sch_cake: Make gso-splitting configurable

-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-isolate

Re: [PATCH iproute2-next 1/3] tc: support conversions to or from 64 bit nanosecond-based time

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

Re: [PATCH v1 6/7] net: mvneta: Don't use GRO on Armada 3720

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

Re: [PATCH v2 iproute2-next 1/3] tc: support conversions to or from 64 bit nanosecond-based time

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, ); > > + if (p == str) > > +

Re: [PATCH v2 net-next 01/14] net: Clear skb->tstamp only on the forwarding path

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,

Re: [PATCH net-next 4/4] act_mirred: use ACT_REDIRECT when possible

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

Re: [bug, bisected] pfifo_fast causes packet reordering

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

Re: [PATCH v2 iproute2-next 1/3] tc: support conversions to or from 64 bit nanosecond-based time

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) > >