ccp-project / ccp-kernel Goto Github PK

View Code? Open in Web Editor NEW

21.0 21.0 8.0 168 KB

A Linux Kernel module implementing support for CCP congestion control algorithms

Home Page: https://ccp-project.github.io/

License: MIT License

Makefile 3.32% Shell 3.20% C 89.75% Python 3.73%

ccp-kernel's People

Contributors

Stargazers

Watchers

Forkers

aditiharini neena sun363587351 therisingstar hexiangdong0 princes17 xiam0 rumjxl

ccp-kernel's Issues

About the order of the parameters to be reported to the ccp agent on Report function

While I am just starting using ccp, I copy your guide page's example code to verify I have done the preparation work, just like this

class AIMD(portus.AlgBase):

    def datapath_programs(self):
        return {
                "default" : """\
                (def (Report
                    (volatile acked 0) 
                    (volatile sacked 0) 
                    (volatile loss 0) 
                    (volatile timeout false)
                    (volatile rtt 0)
                    (volatile inflight 0)
                    (volatile accum_lost 0)   #LOOK HERE
                ))
                (when true
                    (:= Report.inflight Flow.packets_in_flight)
                    (:= Report.rtt Flow.rtt_sample_us)
                    (:= Report.acked  Ack.bytes_acked)
                    (:= Report.sacked (+ Report.sacked Ack.packets_misordered))
                    (:= Report.loss Ack.lost_pkts_sample)
                    (:= Report.timeout Flow.was_timeout)
                    (:= Report.accum_lost (+ Report.accum_lost Ack.lost_pkts_sample))   #LOOK HERE
                    (fallthrough)
                )
                (when (|| Report.timeout (> Report.loss 0))
                    (report)
                    (:= Micros 0)
                )
                (when (> Micros Flow.rtt_sample_us)
                    (report)
                    (:= Micros 0)  
                )
            """
        }

    def new_flow(self, datapath, datapath_info):
        return AIMDFlow(datapath, datapath_info)

As above, I add a parameter named accum_lost to report, and then in the class AIMDFlow, I use print(r.accum_lost) to see its value, just like the following:

def on_report(self, r):
        
        if r.loss > 0 or r.sacked > 0:
            self.cwnd /= 2
        else:
            self.cwnd += (self.datapath_info.mss * (r.acked / self.cwnd))
        
        self.cwnd = max(self.cwnd, self.init_cwnd)
        print(r.accum_lost)
        
        self.datapath.update_field("Cwnd", int(self.cwnd))

then I run alg.py and use iperf3 to test, here are the bugs I encounter

Then I exchange the order of parameters like this(inflight and accum_lost) with all others unchanged and avoid the bug and make it, but I don't know the reason about it, maybe it is a bug of project?

(def (Report
    (volatile acked 0) 
    (volatile sacked 0) 
    (volatile loss 0) 
    (volatile timeout false)
    (volatile rtt 0)
    (volatile accum_lost 0)   #LOOK HERE and compare the parameter order with the above code
    (volatile inflight 0)
))

Waiting for your reply!

ccp_connection not initialized problem

The ccp can not control rate normally,and the dmesg command show "[ccp] ccp_connection not initialized"

Update README

Handle case where CCP crashes

We agreed that we should fallback to some default algorithm (maybe there's a way of specifying a backup algorithm in portus) and that this should be treated as a timeout, so we start over with an initial cwnd rather than trying to pick up where the CCP left off.

We should also add a tiny but of text about this to the paper.

char dev test hangs on virtual machines

example trace from an azure vm

Jun  5 16:23:03 akshayVM kernel: [  466.878318] nltest: loading out-of-tree module taints kernel.
Jun  5 16:23:03 akshayVM kernel: [  466.878356] nltest: module verification failed: signature and/or required key missing - tainting kernel
Jun  5 16:23:07 akshayVM kernel: [  466.880601] nltest: Sending initial message
Jun  5 16:23:07 akshayVM kernel: [  471.257503] ipc = chardev
Jun  5 16:23:07 akshayVM kernel: [  471.257506] ccp-kpipe: device (243) created successfully
Jun  5 16:23:07 akshayVM kernel: [  471.257789] init ccp: 32
Jun  5 16:23:07 akshayVM kernel: [  471.280448] ccp-kpipe: init lfq
Jun  5 16:23:07 akshayVM kernel: [  471.280459] ccp-kpipe: got lock, getting id
Jun  5 16:23:07 akshayVM kernel: [  471.280459] ccp-kpipe: init done
Jun  5 16:23:07 akshayVM kernel: [  471.280504] ccp-kpipe: [writer 0] acquired free block at 0 (head=1, tail=1023)
Jun  5 16:23:07 akshayVM kernel: [  471.280507] BUG: unable to handle kernel paging request at 00007f75e2a1e200
Jun  5 16:23:07 akshayVM kernel: [  471.284380] IP: memcpy_erms+0x6/0x10
Jun  5 16:23:07 akshayVM kernel: [  471.284394] PGD 8000002052e73067
Jun  5 16:23:07 akshayVM kernel: [  471.284394] P4D 8000002052e73067
Jun  5 16:23:07 akshayVM kernel: [  471.284394] PUD 2071ea2067
Jun  5 16:23:07 akshayVM kernel: [  471.284394] PMD 20740d2067
Jun  5 16:23:07 akshayVM kernel: [  471.284394] PTE 8000002036463867
Jun  5 16:23:07 akshayVM kernel: [  471.284394]
Jun  5 16:23:07 akshayVM kernel: [  471.284394] Oops: 0001 [#1] SMP PTI
Jun  5 16:23:07 akshayVM kernel: [  471.284394] Modules linked in: ccp(OE) nf_conntrack_ipv4 nf_defrag_ipv4 xt_owner xt_conntrack nf_conntrack iptable_security nls_iso8859_1 sb_edac kvm_intel kvm irqbypass intel_rapl_perf i2c_piix4 input_leds serio_raw hv_balloon joydev mac_hid ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic crct10dif_pclmul crc32_pclmul ghash_clmulni_intel hid_hyperv hv_utils pcbc hv_storvsc ptp aesni_intel hv_netvsc aes_x86_64 pps_core hid hyperv_keyboard scsi_transport_fc crypto_simd glue_helper cryptd hyperv_fb psmouse pata_acpi floppy hv_vmbus [last unloaded: nltest]
Jun  5 16:23:07 akshayVM kernel: [  471.284394] CPU: 30 PID: 3809 Comm: kptest Tainted: G           OE   4.13.0-43-generic #48-Ubuntu
Jun  5 16:23:07 akshayVM kernel: [  471.284394] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090007  06/02/2017
Jun  5 16:23:07 akshayVM kernel: [  471.284394] task: ffffa0b611f52e80 task.stack: ffffb9225300c000
Jun  5 16:23:07 akshayVM kernel: [  471.284394] RIP: 0010:memcpy_erms+0x6/0x10
Jun  5 16:23:07 akshayVM kernel: [  471.284394] RSP: 0018:ffffb9225300fe70 EFLAGS: 00010286
Jun  5 16:23:07 akshayVM kernel: [  471.284394] RAX: ffffa0b5f1500000 RBX: ffffa0b62884e788 RCX: 0000000000000015
Jun  5 16:23:07 akshayVM kernel: [  471.284394] RDX: 0000000000000015 RSI: 00007f75e2a1e200 RDI: ffffa0b5f1500000
Jun  5 16:23:07 akshayVM kernel: [  471.284394] RBP: ffffb9225300fea8 R08: 0000000000000001 R09: 000000000000024a
Jun  5 16:23:07 akshayVM kernel: [  471.284394] R10: ffffa0b612cbb238 R11: 0000000000000000 R12: 0000000000000000
Jun  5 16:23:07 akshayVM kernel: [  471.284394] R13: ffffa0b5f1500000 R14: 00007f75e2a1e200 R15: 0000000000000000
Jun  5 16:23:07 akshayVM kernel: [  471.284394] FS:  00007f75e3d87380(0000) GS:ffffa0b63dd80000(0000) knlGS:0000000000000000
Jun  5 16:23:07 akshayVM kernel: [  471.284394] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jun  5 16:23:07 akshayVM kernel: [  471.284394] CR2: 00007f75e2a1e200 CR3: 0000002051e74000 CR4: 00000000003406e0
Jun  5 16:23:07 akshayVM kernel: [  471.284394] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jun  5 16:23:07 akshayVM kernel: [  471.284394] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Jun  5 16:23:07 akshayVM kernel: [  471.284394] Call Trace:
Jun  5 16:23:07 akshayVM kernel: [  471.284394]  ? lfq_write+0x61/0x109 [ccp]
Jun  5 16:23:07 akshayVM kernel: [  471.284394]  ccpkp_user_write+0x1e/0x20 [ccp]
Jun  5 16:23:07 akshayVM kernel: [  471.284394]  __vfs_write+0x1b/0x40
Jun  5 16:23:07 akshayVM kernel: [  471.284394]  vfs_write+0xb1/0x1a0
Jun  5 16:23:07 akshayVM kernel: [  471.284394]  SyS_write+0x55/0xc0
Jun  5 16:23:07 akshayVM kernel: [  471.284394]  entry_SYSCALL_64_fastpath+0x24/0xab
Jun  5 16:23:07 akshayVM kernel: [  471.284394] RIP: 0033:0x7f75e3551cc0
Jun  5 16:23:07 akshayVM kernel: [  471.284394] RSP: 002b:00007fff5b2d73d0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
Jun  5 16:23:07 akshayVM kernel: [  471.284394] RAX: ffffffffffffffda RBX: 00007fff5b2d97a8 RCX: 00007f75e3551cc0
Jun  5 16:23:07 akshayVM kernel: [  471.284394] RDX: 0000000000000015 RSI: 00007f75e2a1e200 RDI: 0000000000000003
Jun  5 16:23:07 akshayVM kernel: [  471.284394] RBP: 00007fff5b2d6340 R08: 0000000000000000 R09: 00007f75e2a1f2b0
Jun  5 16:23:07 akshayVM kernel: [  471.284394] R10: 00007fff5b2d7368 R11: 0000000000000293 R12: 00005643f18910e0
Jun  5 16:23:07 akshayVM kernel: [  471.284394] R13: 00007fff5b2d9960 R14: 00007fff5b2d97d0 R15: 0000000000000001
Jun  5 16:23:07 akshayVM kernel: [  471.284394] Code: 78 ff ff ff 90 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38
Jun  5 16:23:07 akshayVM kernel: [  471.284394] RIP: memcpy_erms+0x6/0x10 RSP: ffffb9225300fe70
Jun  5 16:23:07 akshayVM kernel: [  471.284394] CR2: 00007f75e2a1e200
Jun  5 16:23:07 akshayVM kernel: [  471.284394] ---[ end trace d2532dafbc45eeef ]---

Testing / safety

Basically the same thing as ccp-project/libccp#5

Manually scan through the code for any places that are missing error checks / graceful error handling
Write some tests that check a few scenarios and make sure it doesn't ever crash.
Might also be useful to have a bit of logging in case we need to diagnose problems when it's running on Pantheon

Fails with many connections

Currently, the space for connection information is allocated statically on module load. We might want to change this to be dynamic. For now, the size of the static array has been increased.

Shared memory IPC

The current char-dev buffer design should easily work on top of shared memory as well, and would remove the need for user/kernel switch. Might help performance. Might not matter.

using kp crashses kernel

Starting iperf immediately crashes the kernel. Both on https://github.com/ngsrinivas/linux-fork/ and on Ubuntu 18.04 (kernel 4.15.0).

Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.637695] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.645218] IP: lfq_read+0x30/0x2f0 [ccp]
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.647679] PGD 0 P4D 0
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.649381] Oops: 0000 [#1] SMP PTI
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.651540] Modules linked in: ccp(OE) ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat xt_connmark nf_conntr
ack tcp_bbr serio_raw sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov as
ync_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd glue_helper cryptd [last
unloaded: ccp]
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.682958] CPU: 1 PID: 13279 Comm: iperf Tainted: G           OE    4.15.0-1009-aws #9-Ubuntu
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.688134] Hardware name: Xen HVM domU, BIOS 4.2.amazon 08/24/2006
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.691908] RIP: 0010:lfq_read+0x30/0x2f0 [ccp]
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.694753] RSP: 0018:ffffb00c43c77b28 EFLAGS: 00010246
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.697847] RAX: 0000000000000000 RBX: ffff8ac8c6d48000 RCX: 0000000000000000
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.702033] RDX: 0000000000001000 RSI: ffffffffc0819520 RDI: 0000000000000008
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.706117] RBP: ffffb00c43c77ba8 R08: ffffb00c43c77c50 R09: ffffb00c43c77c68
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.710574] R10: fffff9a09ef88000 R11: 000000002135ac4e R12: 0000000000000008
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.715121] R13: 0000000000000000 R14: 000000002135ac4f R15: 000000002135ac4e
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.719497] FS:  00007f3ef6a59700(0000) GS:ffff8ac8ef240000(0000) knlGS:0000000000000000
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.725122] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.729497] CR2: 0000000000000028 CR3: 00000007d76e8006 CR4: 00000000001606e0
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.734010] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.738618] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.743179] Call Trace:
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.745179]  ? tcp_ack_update_rtt.isra.33+0xf5/0x270
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.748439]  ? tcp_clean_rtx_queue+0x33c/0x8d0
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.751768]  ccpkp_try_read+0x31/0x50 [ccp]
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.754746]  tcp_ccp_cong_control+0x1fe/0x220 [ccp]
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.758126]  tcp_ack+0x639/0xa20
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.760504]  ? ip_queue_xmit+0x160/0x3e0
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.763632]  tcp_rcv_state_process+0x169/0xe70
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.766994]  ? tcp_connect+0x7d5/0xc60
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.769762]  ? xen_clocksource_get_cycles+0x15/0x20
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.773173]  tcp_v4_do_rcv+0x135/0x1e0
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.775907]  ? tcp_v4_do_rcv+0x135/0x1e0
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.778822]  __release_sock+0x88/0xe0
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.781510]  release_sock+0x30/0xa0
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.784128]  __inet_stream_connect+0x172/0x350
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.787235]  ? do_wait_intr_irq+0x90/0x90
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.790204]  inet_stream_connect+0x3b/0x60
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.793604]  SYSC_connect+0x9e/0x120
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.796688]  ? tcp_setsockopt+0x34/0x40
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.799656]  ? SyS_setsockopt+0xbb/0xf0
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.802476]  SyS_connect+0xe/0x10
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.804977]  do_syscall_64+0x73/0x130
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.807650]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.810947] RIP: 0033:0x7f3ef706e777
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.813519] RSP: 002b:00007f3ef6a58e60 EFLAGS: 00000293 ORIG_RAX: 000000000000002a
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.818590] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f3ef706e777
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.823146] RDX: 0000000000000010 RSI: 000055f5e0ae9f18 RDI: 0000000000000003
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.827766] RBP: 000055f5e0ae9f18 R08: 0000000000000000 R09: 0000000000000000
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.832317] R10: 000055f5e0aea0b0 R11: 0000000000000293 R12: 0000000000000010
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.836776] R13: 0000000000000000 R14: 000055f5e0ae9e70 R15: 00007ffe5a36d260
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.841134] Code: 55 48 89 e5 41 57 41 56 41 55 41 54 49 89 fc 53 48 83 ec 58 48 89 55 80 48 89 75 a0 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 <80> 7f 20 00 44 0f b7 47 18 0f b7 57 1a 0f 85 c7 00 00 00 31 c0
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.852537] RIP: lfq_read+0x30/0x2f0 [ccp] RSP: ffffb00c43c77b28
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.856395] CR2: 0000000000000028
Jun 11 01:14:15 ip-172-31-31-234 kernel: [  863.859339] ---[ end trace 50ed042de7c42705 ]---

Support kernel > 4.16

Requiring 4.13 < kernel < 4.16 just sounds really narrow, and the issue is (hopefully) tiny

character device should not depend on the ack clock for reading messages

currently try_readmsg() is inside cong_control, should probably be in a separate thread

look into how netlink does this

ccp_connection not initialized, [ccp] [nl] message read failed: -81.

Hi,

I have been using CCP (ccp-kernel) to run my algorithms in python for quite some time now. Recently when I tried running an algorithm, I noticed that the output (overall throughput) appeared to be same, irrespective of the changes in the algorithm. The output remained similar when I tried running different algorithms. Later I noticed this message in /var/log/syslog.

Mar 10 09:53:01 client1 kernel: [323799.383380] [ccp] freeing connection 143
Mar 10 09:53:01 client1 kernel: [323818.435914] [ccp] ccp_connection not initialized
Mar 10 09:53:01 client1 kernel: [323818.435916] [ccp] ccp_connection not initialized
Mar 10 09:53:01 client1 kernel: [323818.435918] [ccp] new flow
Mar 10 09:53:01 client1 kernel: [323818.436027] [ccp] starting connection 143
Mar 10 09:53:01 client1 kernel: [323818.436121] unable to install new program, table is full
Mar 10 09:53:01 client1 kernel: [323818.436124] could not install datapath program: -81
Mar 10 09:53:01 client1 kernel: [323818.436124]
Mar 10 09:53:01 client1 kernel: [323818.436124] [ccp] [nl] message read failed: -81.

I haven't changed anything in ccp-kernel files. Can you please help me with this situation?
Regards,
Ramya

Make a better kptest that uses a fake kernel module

Requested in #12

CCP cannot obtain data error

Hello, I have used the latest version, but this problem still appears. What is the reason？

function getnstimeofday64() been deprecated in new version of linux kernel

while compiling

➜  ccp-kernel git:(master) make
make -C /lib/modules/5.6.3-arch1-1/build M=/home/oocococo/Tools/ccp/ccp-kernel modules
make[1]: Entering directory '/usr/lib/modules/5.6.3-arch1-1/build'
  CC [M]  /home/oocococo/Tools/ccp/ccp-kernel/libccp/serialize.o
  CC [M]  /home/oocococo/Tools/ccp/ccp-kernel/libccp/ccp_priv.o
  CC [M]  /home/oocococo/Tools/ccp/ccp-kernel/libccp/machine.o
  CC [M]  /home/oocococo/Tools/ccp/ccp-kernel/libccp/ccp.o
  CC [M]  /home/oocococo/Tools/ccp/ccp-kernel/ccpkp/ccpkp.o
  CC [M]  /home/oocococo/Tools/ccp/ccp-kernel/ccpkp/lfq/lfq.o
  CC [M]  /home/oocococo/Tools/ccp/ccp-kernel/tcp_ccp.o
/home/oocococo/Tools/ccp/ccp-kernel/tcp_ccp.c: In function ‘ccp_now’:
/home/oocococo/Tools/ccp/ccp-kernel/tcp_ccp.c:78:5: error: implicit declaration of function ‘getnstimeofday64’ [-Werror=implicit-function-declaration]
   78 |     getnstimeofday64(&now);
      |     ^~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:268: /home/oocococo/Tools/ccp/ccp-kernel/tcp_ccp.o] Error 1
make[1]: *** [Makefile:1683: /home/oocococo/Tools/ccp/ccp-kernel] Error 2
make[1]: Leaving directory '/usr/lib/modules/5.6.3-arch1-1/build'
make: *** [Makefile:36: all] Error 2

and after some reference, it seems the function getnstimeofday() had been deprecated and can not be used on v5.6.3, the replacement is ktime_get_real_ts64(), it's been supported since v4.14 (I didn't check kernel older than it).
So I replace all the four getnstimeofday64(&now) with ktime_get_real_ts64(&now), and it works.

ccp_connection not initialized problem

I found that sometimes the ccp-kernel can not work normally.When I use "dmesg" command,the kernel log showes "[11447.630107] [ccp] ccp_connection not initialized".To fix this bug,change the code of function tcp_ccp_register() in the tcp_ccp.c as follows:

static int __init tcp_ccp_register(void) {
int ok,sid;
struct ccp_connection *conn;
getnstimeofday64(&tzero);

#ifdef COMPAT_MODE
pr_info("[ccp] Compatibility mode: 4.13 <= kernel version <= 4.16\n");
#endif
#ifdef RATESAMPLE_MODE
pr_info("[ccp] Rate-sample mode: 4.19 <= kernel version\n");
#endif

kernel_datapath = kmalloc(sizeof(struct ccp_datapath), GFP_KERNEL);
if(!kernel_datapath) {
    pr_info("[ccp] could not allocate ccp_datapath\n");
    return -4;
}

kernel_datapath->max_connections = MAX_ACTIVE_FLOWS;
kernel_datapath->ccp_active_connections =
    (struct ccp_connection *) kmalloc(sizeof(struct ccp_connection) * MAX_ACTIVE_FLOWS, GFP_KERNEL);
if(!kernel_datapath->ccp_active_connections) {
    pr_info("[ccp] could not allocate ccp_active_connections\n");
    return -5;
}

//folowing 4 line code added by zhujiahua to fix the bug "[ccp] ccp_connection not initialized"!
for (sid = 0; sid < kernel_datapath->max_connections; sid++) {
conn = & kernel_datapath->ccp_active_connections[sid];
conn->index=0;
}


kernel_datapath->max_programs = MAX_DATAPATH_PROGRAMS;
kernel_datapath->set_cwnd = &do_set_cwnd;
kernel_datapath->set_rate_abs = &do_set_rate_abs;
kernel_datapath->now = &ccp_now;
kernel_datapath->since_usecs = &ccp_since;
kernel_datapath->after_usecs = &ccp_after;
kernel_datapath->log = &ccp_log;

#if IPC == IPC_NETLINK
ok = ccp_nl_sk(&ccp_read_msg);//创建netlink
if (ok < 0) {
return -1;
}

kernel_datapath->send_msg = &nl_sendmsg;
pr_info("[ccp] ipc = netlink\n");

#elif IPC == IPC_CHARDEV
ok = ccpkp_init(&ccp_read_msg);
if (ok < 0) {
return -2;
}

kernel_datapath->send_msg = &ccpkp_sendmsg;
pr_info("[ccp] ipc = chardev\n");

#else
pr_info("[ccp] ipc = %s unknown\n", IPC);
return -3;
#endif

ok = ccp_init(kernel_datapath);//检查kernel_datapath的set_cwnd()等函数是否设置
if (ok < 0) {
    return -6;
}

pr_info("[ccp] init\n");
return tcp_register_congestion_control(&tcp_ccp_congestion_ops);

}

Kernel module fails to load (Ubuntu 20.10, Kernel 5.8)

Recently I wanted to load the CCP kernel module to test the Copa congestion control algorithm, but came across this error when running sudo ./ccp_kernel_load ipc=0 as described in the guide:

make -C /lib/modules/5.8.0-7642-generic/build M=/home/rafi/Development/Repos/ccp-kernel modules
make[1]: Entering directory '/usr/src/linux-headers-5.8.0-7642-generic'
make[1]: Leaving directory '/usr/src/linux-headers-5.8.0-7642-generic'
insmod: ERROR: could not insert module ./ccp.ko: File exists
[  254.926144] vboxdrv: 0000000000000000 VBoxDDR0.r0
[  254.955675] VMMR0InitVM: eflags=246 fKernelFeatures=0x0 (SUPKERNELFEATURES_SMAP=0)
[ 1032.826829] VMMR0InitVM: eflags=246 fKernelFeatures=0x0 (SUPKERNELFEATURES_SMAP=0)
[ 1422.358600] vboxdrv: 0000000000000000 VMMR0.r0
[ 1422.450674] vboxdrv: 0000000000000000 VBoxDDR0.r0
[ 1422.475581] VMMR0InitVM: eflags=246 fKernelFeatures=0x0 (SUPKERNELFEATURES_SMAP=0)
[ 1565.455151] vboxdrv: 0000000000000000 VMMR0.r0
[ 1565.562340] vboxdrv: 0000000000000000 VBoxDDR0.r0
[ 1565.585402] VMMR0InitVM: eflags=246 fKernelFeatures=0x0 (SUPKERNELFEATURES_SMAP=0)
[ 1648.440037] VMMR0InitVM: eflags=246 fKernelFeatures=0x0 (SUPKERNELFEATURES_SMAP=0)
reno cubic ccp
tee: /proc/sys/net/ipv4/tcp_allowed_congestion_control: No such file or directory

Came across this on PopOS 20.10, which is very similar to Ubuntu 20.10, using Kernel version 5.8.0-7642-generic. I tried this on Arch Linux as well and ran into the same issue. I'd appreciate any advice about how to solve this! Thanks in advance.

Put header guards around accessing rate sample

Right now, to access the rate sample without a kernel patch, we use code that only works on kernel versions 4.13 <= version < 4.16. Since the kernel patch has been merged into 4.19, we should remove this code that calculates the rate sample (or atleast put header guards around it) and say we support only 4.19 or greater or forward -> or are backwards compatible with 4.13 < v < 4.16.