Announcement

Collapse
No announcement yet.

Networking CAKE Is Ready For Tasting With Linux 4.19

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Networking CAKE Is Ready For Tasting With Linux 4.19

    Phoronix: Networking CAKE Is Ready For Tasting With Linux 4.19

    For those maintaining their own home-built Linux router, Linux 4.19 is going to be pretty exciting: CAKE Qdisc has been merged into net-next, making it a feature for this next kernel cycle...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Good stuff, very good stuff. Nice to see they went the extra mile to get it merged.

    Comment


    • #3
      Ok, I decided to apply this even though there are still bits I'm not %100 happy with. I don't like the netfilter dependency at all. You can get the NAT addresses in other ways as I've tried to suggest in the past. Your scheme absolutely does not work with act_nat in the packet scheduler, not any NAT done by XDP/eBPF programs.
      Requires netfilter.
      Will not work with programs that use XDP/eBDF to acquire NAT

      See Nic's write up on the purpose of XDP/eBDF to understand what it does.


      Comment


      • #4
        The cake is a lie...

        Sorry, I had to. As for the real CAKE, good stuff. That was one of the reasons I upgraded my router with an OpenWRT (actually LEDE) compatible. It really helped when I had a slow 28/1 connection.

        Comment


        • #5
          Could you use this to tell the kernel to always prioritize outgoing UDP packets over TCP packets? IE TCP packets will always be queued up in the event there are unsent UDP packets in the buffer.

          Comment


          • #6
            Originally posted by cybertraveler View Post
            Could you use this to tell the kernel to always prioritize outgoing UDP packets over TCP packets? IE TCP packets will always be queued up in the event there are unsent UDP packets in the buffer.
            You wouldn't actually want that, unless you have a very special awareness of your traffic. It's never good to prioritize any one type of traffic 100% over another. Instead it's best to prioritize whichever traffic classes and hosts/connections have the lowest total bidirectional utilization in a window so that all classes experience the lowest latency. For example, if you are assuming that UDP will be used for low-bandwidth low-latency signalling and you want it to be serviced first so that your gaming response times will be ideal. But then your girlfriend fires up qBittorrent which is using UDP for its new transport... the way you just asked things to be done your gaming latency would get clobbered.

            Comment


            • #7
              Originally posted by linuxgeex View Post

              You wouldn't actually want that, unless you have a very special awareness of your traffic. It's never good to prioritize any one type of traffic 100% over another. Instead it's best to prioritize whichever traffic classes and hosts/connections have the lowest total bidirectional utilization in a window so that all classes experience the lowest latency. For example, if you are assuming that UDP will be used for low-bandwidth low-latency signalling and you want it to be serviced first so that your gaming response times will be ideal. But then your girlfriend fires up qBittorrent which is using UDP for its new transport... the way you just asked things to be done your gaming latency would get clobbered.
              I know what all the traffic is on my network. I worked out that simply always prioritizing all UDP outbound traffic will have a positive effect on my applications. There's nothing on my network that uses UDP for heavy throughput or batch jobs. Everything using UDP requires small amounts of data at low latency.

              So I do want that, I just haven't figured out how to implement it yet. I want a simple solution for my very simple requirement.

              Comment


              • #8
                The cake is a lie

                Comment


                • #9
                  Originally posted by bofh80

                  Had a fish around as it seems quite interesting, found cisco docs straight away, not more use here tho.

                  So it seems you want tc and sfq . As best as I can find.
                  http://www.cs.dartmouth.edu/~sergey/...9_modified.pdf (part 3)
                  http://linux-ip.net/articles/Traffic...ss-qdiscs.html

                  Be interested if you get anywhere (note the compiled kernel is only for the printk testing, not required)
                  Thanks! I'll give them a read.

                  Comment


                  • #10
                    Originally posted by cybertraveler View Post

                    I know what all the traffic is on my network. I worked out that simply always prioritizing all UDP outbound traffic will have a positive effect on my applications. There's nothing on my network that uses UDP for heavy throughput or batch jobs. Everything using UDP requires small amounts of data at low latency.

                    So I do want that, I just haven't figured out how to implement it yet. I want a simple solution for my very simple requirement.
                    iptables can do that by tagging UDP packets and TCP packets for different queues and then prioritizing the UDP queue, but I'm not an iptables guru. Maybe try StackExchange.

                    hmm... here's an example that prioritizes different TCP packet types over ICMP and UDP, so you should be able to just swap the queues around and that should give you the result you want:

                    http://www.fyzix.net/index.php?title...c_and_iptables
                    Last edited by linuxgeex; 24 July 2018, 02:19 AM.

                    Comment

                    Working...
                    X