Giter Club home page Giter Club logo

rcore_plus's People

Contributors

benjaminpmlovegood avatar benpigchu avatar cfgbd avatar chenqiuhao1997 avatar chyyuu avatar circuitcoder avatar eatenbagpipe avatar equation314 avatar gjz010 avatar harry-chen avatar hoblovski avatar jackey-huo avatar jiegec avatar koumingyang avatar lcy1996 avatar loremkang avatar maoyuchaxue avatar miskcoo avatar naginikaido avatar panql avatar phil-opp avatar prettykernel avatar ssryps avatar wangrunji0408 avatar xy-plus avatar xyongcn avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

rcore_plus's Issues

What's the meaning of '&*'?

......
    fn force_get<'a>(&'a self) -> &'a T {
        match unsafe { &*self.data.get() }.as_ref() {
            None    => unsafe { unreachable() },
            Some(p) => p,
        }
    }

What's the meaning of '&*'? @wangrunji0408

the write operation on device?

目前lab8-rv32中,用mem来模拟disk。但我看到两种对Device::read_at/write_at的实现:

impl Device for MemBuf {
    fn read_at(&mut self, offset: usize, buf: &mut [u8]) -> Option<usize> {
        let slice = self.0;
        let len = buf.len().min(slice.len() - offset);
        buf[..len].copy_from_slice(&slice[offset..offset + len]);
        Some(len)
    }
    fn write_at(&mut self, _offset: usize, _buf: &[u8]) -> Option<usize> {
        None
    }
}

/// Device which can only R/W in blocks
pub trait BlockedDevice: Send {
    const BLOCK_SIZE_LOG2: u8;
    fn read_at(&mut self, block_id: usize, buf: &mut [u8]) -> bool;
    fn write_at(&mut self, block_id: usize, buf: &[u8]) -> bool;
}
...
/// Helper functions to R/W BlockedDevice in bytes
impl<T: BlockedDevice> Device for T {
    fn read_at(&mut self, offset: usize, buf: &mut [u8]) -> Option<usize> {...
    fn write_at(&mut self, offset: usize, buf: &[u8]) -> Option<usize> {...

我理解sfs应该用的是BlockedDevice的struct,但MemBuf 没有包括BlockedDevice的实现,且没有write_at的实现。

如何理解sfs中的虚拟设备是如何实现的?

@wangrunji0408

question about impl mutex?

kernel/src/sync/mutex.rs

/// Spin & no-interrupt lock
#[derive(Debug)]
pub struct SpinNoIrq;
...
impl MutexSupport for SpinNoIrq {
    type GuardData = FlagsGuard;
    fn new() -> Self {
        SpinNoIrq
    }
    fn cpu_relax(&self) {
        unsafe {cpu::cpu_relax();};
    }

在new()函数中的SpinNoIrq写法不太理解。感觉就是一个空结构。
cpu_relax()函数的作用也没看出来。

@wangrunji0408

Optimize gcc

Thanks to @jiegec, x86_64-linux-musl-gcc is now working on rCore! 🎉

But now it takes nearly 10s (on QEMU) to build a simple C source file.
It's time to find the bottleneck and do some optimization!

  • implement delay mapping files
  • implement vfork

Test rCore on x86_64 real machine

  • Enable VGA 320x200
  • Fix VGA text color and kill escape code
  • Fix keyboard input (it's actually VGA bug)
  • Fix multicore boot
  • Fix serial dead lock
  • Fix other bugs

Flush remote TLB

There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton

Current status:

Arch Status Note
x86_64 ⚠️ significantly slow when enabled
RISC-V implemented by SBI
AArch64 ✖️ single core, unnecessary
MIPS ✖️ single core, unnecessary

Test rCore on HiFive Unleashed (riscv64)

Problems & Solutions

  • Build image and write it to SD card.
    • Add mkimg script from twd2/sv6
  • CPU0 does not have S-Mode.
    • Set hart1 as boot core.
  • HiFiveU will raise page fault when access page A=0 or D=0.
    • Set A=D=1 for all PTE at bbl and riscv crate.
  • Unidentified supervisor external interrupt after SEIE is set.
    • Set PLIC Interrupt Enable Register. Mask all except serial.
  • Can not receive serial input when using minicom
    • Serial Port setup -- Hardware Flow Control -- NO
  • Can not receive serial interrupt
    • Set UART Interrupt Enable Register at bbl
  • Can not complete serial interrupt
    • Read and write PLIC Interrupt Claim/Complete Register

Acknowledgement

Special thanks to @twd2 for porting sv6 and helping me debug

Correctly handle memory area alignment issue

Problem:
/bin/ls does not work.

Reason:
User passed a pointer 0x92158, but the memory area spans from 0x8ebc0 to 0x92130.

Question:
Should memory areas align to page boundary?

readelf -e ld-musl-x86_64.1.so:

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000016590 0x0000000000016590  R      0x1000
  LOAD           0x0000000000017000 0x0000000000017000 0x0000000000017000
                 0x0000000000044781 0x0000000000044781  R E    0x1000
  LOAD           0x000000000005c000 0x000000000005c000 0x000000000005c000
                 0x0000000000031704 0x0000000000031704  R      0x1000
  LOAD           0x000000000008dbc0 0x000000000008ebc0 0x000000000008ebc0
                 0x00000000000008d4 0x0000000000003570  RW     0x1000

Fix sys_futex race condition

According to the specification:

FUTEX_WAIT (since Linux 2.6.0)
This operation tests that the value at the futex word pointed
to by the address uaddr still contains the expected value val,
and if so, then sleeps waiting for a FUTEX_WAKE operation on
the futex word. The load of the value of the futex word is an
atomic memory access (i.e., using atomic machine instructions
of the respective architecture). This load, the comparison
with the expected value, and starting to sleep are performed
atomically and totally ordered with respect to other futex
operations on the same futex word.
If the thread starts to
sleep, it is considered a waiter on this futex word. If the
futex value does not match val, then the call fails
immediately with the error EAGAIN.

Now the load and sleep is not an atomic operation on futex.

So if events happen as the following:
Thread A wants to wait futex. Thread B wants to wake futex.

  1. Thread A loads the word at kernel space.
  2. Thread B stores the word at user space.
  3. Thread B wakes up the queue at kernel space.
  4. Thread A sleeps at the queue at kernel space.

Then thread A will sleep forever. GG.

biscuit/ls error on ubuntu16.04 x86_64

The output lools like this:

Hello world! from CPU 1!
Hello world! from CPU 2!
Hello world! from CPU 3!
Hello world! from CPU 0!
Available programs: [".", "..", "busybox", "rust", "biscuit"]

biscuit/ls
[ERROR]
EXCEPTION: Page Fault @ 0xffffffffffffffd0, code: PRESENT | WRITE | USER
[ERROR] TrapFrame {
fpstate_offset: 0x8,
fpstate: fpstate,
fsbase: 0x0,
r15: 0x0,
r14: 0x0,
r13: 0x2,
r12: 0x2,
rbp: 0x180000ffe30,
rbx: 0x0,
r11: 0x0,
r10: 0x0,
r9: 0x1000,
r8: 0x3,
rsi: 0x902,
rdi: 0x4a8927,
rdx: 0xffffffffffffffd0,
rcx: 0x0,
rax: 0x2,
trap_num: 0xe,
error_code: 0x7,
rip: 0x41204d,
cs: 0x13,
rflags: 0x213,
rsp: 0x180000ffdb0,
ss: 0x1b
}
[ERROR] On CPU0 Process 1

user: compiling error

in rcore_plus/user
'RUST_BACKTRACE=1 make sfsimg arch=x86_64'
got error:

make[1]: Leaving directory '/media/chyyuu/chydata/thecode/rust-related/mytest/rcore_plus/user/biscuit/build'
mksfs zip build/x86_64 build/x86_64.img
thread 'main' panicked at 'no space', src/libcore/option.rs:1008:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:211
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:491
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:398
   6: rust_begin_unwind
             at src/libstd/panicking.rs:325
   7: core::panicking::panic_fmt
             at src/libcore/panicking.rs:95
   8: core::option::expect_failed
             at src/libcore/option.rs:1008
   9: simple_filesystem::sfs::INodeImpl::_resize
  10: mksfs::zip_dir
  11: mksfs::zip_dir
  12: mksfs::main
  ...
  19: _start
Makefile:60: recipe for target 'build/x86_64.img' failed
make: *** [build/x86_64.img] Error 101

and I found the error was from mksfs.

mksfs zip build/x86_64 build/x86_64.img

How to fix it?

After switching to OpenSBI, rCore no longer runs on HiFive Unleashed.

It traps right after setting satp:

OpenSBI v0.3 (Apr 19 2019 23:38:37)
   ____                    _____ ____ _____
  / __ \                  / ____|  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |____) | |_) || |_
  \____/| .__/ \___|_| |_|_____/|____/_____|
        | |
        |_|

Platform Name          : SiFive Freedom U540
Platform HART Features : RV64ACDFIMSU
Platform Max HARTs     : 5
Current Hart           : 4
Firmware Base          : 0x80000000
Firmware Size          : 84 KB
Runtime SBI Version    : 0.1

PMP0: 0x0000000080000000-0x000000008001ffff (A)
PMP1: 0x0000000000000000-0x0000007fffffffff (A,R,W,X)
sbi_trap_error: hart4: trap handler failed (error -5)
sbi_trap_error: hart1: trap handler failed (error -5)
sbi_trap_error: hart2: trap handler failed (error -5)
sbi_trap_error: hart1: mcause=0x0000000000000001 mtval=0xffffffffc0207c0e
sbi_trap_error: hart2: mcause=0x0000000000000001 mtval=0xffffffffc0207c0e
sbi_trap_error: hart1: mepc=0xffffffffc0207c0e mstatus=0x8000000a00006800
sbi_trap_error: hart2: mepc=0xffffffffc0207c0e mstatus=0x8000000a00006800
sbi_trap_error: hart1: ra=0x000000008000073c sp=0xffffffffc0cd5000
sbi_trap_error: hart3: trap handler failed (error -5)
sbi_trap_error: hart1: gp=0x0000000000000000 tp=0x0000000080012e00
sbi_trap_error: hart3: mcause=0x0000000000000001 mtval=0xffffffffc0207c0e
sbi_trap_error: hart2: ra=0x000000008000073c sp=0xffffffffc0ce5000
sbi_trap_error: hart1: s0=0x0000000080012d90 s1=0x0000000080012e00
sbi_trap_error: hart2: gp=0x0000000000000000 tp=0x0000000080010e00
sbi_trap_error: hart1: a0=0x0000000000000001 a1=0x0000000082200000
sbi_trap_error: hart2: s0=0x0000000080010d90 s1=0x0000000080010e00
sbi_trap_error: hart1: a2=0x0000000080200000 a3=0x0000000000000001
sbi_trap_error: hart2: a0=0x0000000000000002 a1=0x0000000082200000
sbi_trap_error: hart1: a4=0x0000000000000800 a5=0x0000000000000001
sbi_trap_error: hart3: mepc=0xffffffffc0207c0e mstatus=0x8000000a00006800
sbi_trap_error: hart2: a2=0x0000000080200000 a3=0x0000000000000001
sbi_trap_error: hart1: a6=0x0000000082200000 a7=0x0000000080200000
sbi_trap_error: hart2: a4=0x0000000000000800 a5=0x0000000000000001
sbi_trap_error: hart1: s2=0x0000000080009550 s3=0x0000000000000001
sbi_trap_error: hart3: ra=0x000000008000073c sp=0xffffffffc0cf5000
sbi_trap_error: hart1: s4=0x0000000000000000 s5=0x0000000000000000
sbi_trap_error: hart2: a6=0x0000000082200000 a7=0x0000000080200000
sbi_trap_error: hart1: s6=0x0000000000000001 s7=0x0000000000000005
sbi_trap_error: hart2: s2=0x0000000080009550 s3=0x0000000000000002
sbi_trap_error: hart1: s8=0x0000000000002000 s9=0x0000000000000000
sbi_trap_error: hart3: gp=0x0000000000000000 tp=0x000000008000ee00
sbi_trap_error: hart1: s10=0x0000000000000000 s11=0x0000000000000000
sbi_trap_error: hart2: s4=0x0000000000000000 s5=0x0000000000000000
sbi_trap_error: hart1: t0=0xffffffffc0207c0e t1=0x8000000000000000
sbi_trap_error: hart2: s6=0x0000000000000002 s7=0x0000000000000005
sbi_trap_error: hart1: t2=0x0000000000000001 t3=0x0000000000000000
sbi_trap_error: hart2: s8=0x0000000000002000 s9=0x0000000000000000
sbi_trap_error: hart1: t4=0x0000000000000000 t5=0x0000000000000000
sbi_trap_error: hart2: s10=0x0000000000000000 s11=0x0000000000000000
sbi_trap_error: hart1: t6=0x0000000082200000
sbi_trap_error: hart2: t0=0xffffffffc0207c0e t1=0x8000000000000000
sbi_trap_error: hart3: s0=0x000000008000ed90 s1=0x000000008000ee00
sbi_trap_error: hart2: t2=0x0000000000000001 t3=0x0000000000000000
sbi_trap_error: hart3: a0=0x0000000000000003 a1=0x0000000082200000
sbi_trap_error: hart2: t4=0x0000000000000000 t5=0x0000000000000000
sbi_trap_error: hart3: a2=0x0000000080200000 a3=0x0000000000000001
sbi_trap_error: hart2: t6=0x0000000082200000
sbi_trap_error: hart3: a4=0x0000000000000800 a5=0x0000000000000001
sbi_trap_error: hart4: mcause=0x0000000000000001 mtval=0xffffffffc0207c0e
sbi_trap_error: hart3: a6=0x0000000082200000 a7=0x0000000080200000
sbi_trap_error: hart4: mepc=0xffffffffc0207c0e mstatus=0x8000000a00006800
sbi_trap_error: hart3: s2=0x0000000080009550 s3=0x0000000000000003
sbi_trap_error: hart4: ra=0x000000008000073c sp=0xffffffffc0d05000
sbi_trap_error: hart3: s4=0x0000000000000000 s5=0x0000000000000000
sbi_trap_error: hart4: gp=0x0000000000000000 tp=0x000000008000ce00
sbi_trap_error: hart3: s6=0x0000000000000003 s7=0x0000000000000005
sbi_trap_error: hart4: s0=0x000000008000cd90 s1=0x000000008000ce00
sbi_trap_error: hart3: s8=0x0000000000002000 s9=0x0000000000000000
sbi_trap_error: hart4: a0=0x0000000000000004 a1=0x0000000082200000
sbi_trap_error: hart3: s10=0x0000000000000000 s11=0x0000000000000000
sbi_trap_error: hart4: a2=0x0000000080200000 a3=0x0000000000000001
sbi_trap_error: hart3: t0=0xffffffffc0207c0e t1=0x8000000000000000
sbi_trap_error: hart4: a4=0x0000000000000800 a5=0x0000000000000001
sbi_trap_error: hart3: t2=0x0000000000000001 t3=0x0000000000000000
sbi_trap_error: hart4: a6=0x0000000082200000 a7=0x0000000080200000
sbi_trap_error: hart3: t4=0x0000000000000000 t5=0x0000000000000000
sbi_trap_error: hart4: s2=0x0000000080009550 s3=0x0000000000000004
sbi_trap_error: hart3: t6=0x0000000082200000
sbi_trap_error: hart4: s4=0x0000000000000000 s5=0x0000000000000000
sbi_trap_error: hart4: s6=0x0000000000000004 s7=0x0000000000000005
sbi_trap_error: hart4: s8=0x0000000000002000 s9=0x0000000000000000
sbi_trap_error: hart4: s10=0x0000000000000000 s11=0x0000000000000000
sbi_trap_error: hart4: t0=0xffffffffc0207c0e t1=0x8000000000000000
sbi_trap_error: hart4: t2=0x0000000000000001 t3=0x0000000000000000
sbi_trap_error: hart4: t4=0x0000000000000000 t5=0x0000000000000000
sbi_trap_error: hart4: t6=0x0000000082200000

为啥不把OS的文件系统跟区块链进行结合呢?

用区块链来保证系统重要文件不被非法篡改,而且系统启动的时候就可以联网进行交叉验证,使用密码学非对称加密验证核心文件的签名,验证所有文件的hash,这应该是一个很有意义的方向。

Simplify virtual memory management

The current code structure is confusing!
The recursive mapping is really hard to understand and make the code more complicated.

BlogOS has replaced recursive mapping by linear mapping all physical memory.
See discussions here: phil-opp/blog_os#545.

Some ideas:

  • Deprecate InactivePageTable and only access ActivePageTable

    • Remove remap_the_kernel from kernel.
    • Build a fine page table for kernel in bootloader (as x86_64 did).
    • Let MemorySet owns &'static mut ActivePageTable
  • Move arch-specific page table implementation to memory crate

Prepare to merge biscuit branch to master and release rCore v0.2

What's new in rCore v0.2?

  • Support native Linux musl static programs:
    • Rust std for x86_64-unknown-linux-musl target
    • Busybox
    • Biscuit programs on musl
  • Support basic file system and socket syscalls

TODO

  • FS: Update mksfs to rcore-fs-fuse
  • User: add Redis and Nginx
  • User: pass Travis CI
  • Travis CI: make sure compiling pass on all arch
  • Travis CI: auto test for some biscuit programs on x86_64
  • Net: Intel 82599 driver and improve performance (offload)
  • Optimize imports and run cargo fmt
  • Update README

Discussion of socket implementation

  • Is it possible to treat a socket as a file directly?
    sockfs: impl INode for Socket
  • If we can, what should be added to the current VFS?
  • If not, can we design a socket trait to isolate syscall and network stack?

@jiegec Orz

Merge new features from OS2019 projects

OS2019 projects

GBA

MIPS

Router

LKM

Audio on Raspi3

SD driver on Raspi3

Linear mapping does not work on raspi3 real machine

Commit: e63f11d
Build command:

make arch=aarch64 LOG=info graphic=on

Serial port log (with some debug info):

Hello Raspberry Pi!
[ INFO][-] FrameAllocator init end
[ INFO][-] heap init end
[ INFO][-] memory: init end
[ INFO][-] framebuffer: init end
Framebuffer {
    fb_info: FramebufferInfo {
        xres: 0x500,
        yres: 0x2d0,
        xres_virtual: 0x500,
        yres_virtual: 0x2d0,
        xoffset: 0x0,
        yoffset: 0x0,
        depth: 0x10,
        pitch: 0xa00,
        bus_addr: 0xfea38000,
        screen_size: 0x1c2000
    },
    color_depth: ColorDepth16,
    color_config: RGB565,
    base_addr: 0xffff00003ea38000
}
[ INFO][-] timer: init end
[ INFO][-] console: init end

    ____                __   ____  _____
   / __ \ __  __ _____ / /_ / __ \/ ___/
  / /_/ // / / // ___// __// / / /\__ \
 / _, _// /_/ /(__  )/ /_ / /_/ /___/ /
/_/ |_| \__,_//____/ \__/ \____//____/

[ INFO][-] SFS linked to kernel, from ffff000000158088 to ffff000001fee290
[ERROR][-] MAP BEGIN 0 126cec
[ERROR][-] MAP END
[ERROR][-] MAP BEGIN 137780 5648
[ERROR][-] MAP END
[ERROR][-] MAP BEGIN 7ffffff00000 fc000
[ERROR][-] MAP END
[ERROR][-] MAP BEGIN 7fffffffc000 4000
[ERROR][-] MAP END
[ INFO][-] process: init end
[ERROR][0] ESR: 0x8200000e, Syndrome: InstructionAbort { kind: Permission, level: 2 }, elr: 84dc
[ WARN][0] 
handle_page_fault OK @ 0x84dc elr 0x84dc
[ERROR][0] ESR: 0x92000007, Syndrome: DataAbort { kind: Translation, level: 3 }, elr: 8588
[ WARN][0] 
handle_page_fault OK @ 0x13ac38 elr 0x8588
[ERROR][0] ESR: 0x92000007, Syndrome: DataAbort { kind: Translation, level: 3 }, elr: 85a4
[ WARN][0] 
handle_page_fault OK @ 0x40 elr 0x85a4
[ERROR][0] ESR: 0x92000047, Syndrome: DataAbort { kind: Translation, level: 3 }, elr: 867c
[ WARN][0] 
handle_page_fault OK @ 0x137780 elr 0x867c
[ERROR][0] ESR: 0x8200000e, Syndrome: InstructionAbort { kind: Permission, level: 2 }, elr: 867c
[ERROR][0] 
EXCEPTION: Page Fault @ 0x867c elr 0x867c
[ERROR][0] TrapFrame {
    elr: 0x867c,
    spsr: 0x60000340,
    sp: 0x7ffffffffd70,
    tpidr: 0x0,
    x1to29: [
        0x1c8,
        0x84a8,
        0x875c,
        0x7fffffffff70,
        0x137780,
        0x0,
        0x0,
        0x0,
        0x0,
        0x0,
        0x0,
        0x0,
        0x0,
        0x0,
        0x0,
        0x0,
        0x0,
        0x0,
        0x0,
        0x0,
        0x0,
        0x0,
        0x0,
        0x0,
        0x0,
        0x0,
        0x0,
        0x0,
        0x0
    ],
    __reserved: 0x0,
    x30: 0x0,
    x0: 0x0
}
[ERROR][0] On CPU0 Thread 0
[ERROR][-] UNMAP BEGIN 0 126cec
[ERROR][-] UNMAP END
[ERROR][-] UNMAP BEGIN 137780 5648
[ERROR][-] UNMAP END
[ERROR][-] UNMAP BEGIN 7ffffff00000 fc000
[ERROR][-] UNMAP END
[ERROR][-] UNMAP BEGIN 7fffffffc000 4000
[ERROR][-] UNMAP END
[ INFO][-] PageTable dropping: PhysFrame[4KiB](0x3b3ff000)

Improve IXGBE driver performance

Based on iperf.

Current status (tcp, maximum observed):
rcore -> linux 1.24Gb/s -> 1.40Gb/s -> 2.18Gb/s -> 2.62Gb/s -> 3.50Gb/s
linux -> rcore 308Mb/s -> 320Mb/s -> 379Mb/s -> 407Mb/s -> 1.40Gb/s -> 2.47Gb/s -> 2.53Gb/s -> 3.74Gb/s -> 4.44Gb/s

Udp is not working because smoltcp does not support segmentation.

Possible ways to improve:

  • IP checksum TX
  • IP checksum RX: little improvement
  • UDP checksum TX
  • UDP checksum RX
  • TCP checksum TX
  • TCP checksum RX
  • TCP segmentation offload
  • Interrupt throttling: good for tx, bad for rx without spinning
  • Spin for some times before waiting for condvar: observable improvement for rx
  • Enlarge TCP recv/trans buffers: observable improvement for rx
  • Replace linked_list_allocator with buddy_system_allocator: a little improvement for rx
  • Enable jumbo frame: observable improvement

Manually disable RX checksum for smoltcp seems to have little improvement.

I think we have met smoltcp's performance limit.

Test under linux:

Put two interfaces into two netns, then use iperf to test:

tcp: 9.38Gb/s

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.